21.11.2017 tarihinde saat 16:16’da, Türkiye’de bulunan 19 bankanın toplam 535 çalışanına [email protected] e-posta adresinden Changes to the terms başlığına sahip, ekinde Swift Changes.rtf dosyası bulunan bir e-posta gönderildi ve çoğu bankanın kullanmış olduğu güvenlik sistemleri tarafından ya silindi ya da karantinaya alındı.
Güvenlik sistemlerinde çok sayıda alarma yol açan bu şüpheli e-posta incelendiğinde, başlıkta ve ekindeki dosyada Swift kelimesinin geçmesinin yanısıra, alıcı listesinde (To:) yabancı banka çalışanlarının da dahil olduğu tam 952 kişinin yer alıyor olması ve e-postanın ileti gövdesinde (body) herhangi bir metnin yer almaması şüpheleri fazlasıyla arttırıyordu. E-postanın başlık bilgileri incelendiğinde, gönderen SMTP sunucusunun gerçekten de ProFIX firmasına ait olması ilk olarak bu kurumun hacklenmiş olabileceğine işaret ediyordu. Kim bu ProFIX diye ufak bir araştırma yapıldığında, 29 ülkede 250‘den fazla banka ile çalışan, 2013 yılından bu yana ise Belarus, Ermenistan, Gürcistan, Ukrayna ve Moldovya‘da hizmet veren bir SWIFT iş ortağı olduğu anlaşılıyordu.
Swift Changes.rtf dosyası incelendiğinde ise bu dosyanın içinde Microsoft Office 2007’den 2016’ya kadar tüm sürümlerini etkileyen bir zafiyeti (CVE-2017-11882) istismar eden bir istismar kodu olduğu ortaya çıktı. 14 Kasım‘da Microsoft tarafından yaması yayınlanan, GitHub üzerinde ise 20 Kasım‘da istismar kodu yayınlanan bir zafiyet, 21 Kasım‘da Türkiye’deki 19 bankaya siber saldırı gerçekleştirmek amacıyla, hacklendiği düşünülen ProFIX isimli bir SWIFT iş ortağı üzerinden gerçekleştiriliyordu!
Bulmacının kayıp parçalarını birleştirdikçe ortaya zamanlaması muazzam, senaryosu amatörce ((To: kısmında 952 kişinin olması, ileti gövdesinde metin olmaması vs.) kurgulanmış bir siber saldırı girişimi çıktı. 952 e-posta adresinin nereden ve nasıl temin edildiği sorusuna tam olarak yanıt bulunamasa da, sosyal medya üzerinde siber güvenlik uzmanlarından Huzeyfe ÖNAL ve Furkan ÇALIŞKAN‘ın tespitlerine göre 25 Eylül tarihinde Pastebin sitesinde yer alan bir liste baz alınmıştı. 952 e-posta adresi ile Pastebin’de yer alan bu liste karşılaştırıldığında e-posta adreslerinin çok büyük bir oranının bu liste ile örtüşüyor olması, güvenlik uzmanlarını doğrular nitelikteydi.
22 Kasım tarihinde Carbon Black firmasının blog sayfasında bu siber saldırının özet teknik detaylarına IOCleri ile birlikte yer verildi. 30 Kasım tarihli FireEye iSight istihbarat raporuna bakıldığında bu grubun 2016 yılından bu yana 19 ülkedeki finansal kurumları Cobalt Strike sızma testi yazılımı ile hedef alan Cobalt grubu (diğer bir adıyla MetaStrike) olduğu anlaşılıyordu. 8 Aralık tarihinde ise Palo Alto Networks firmasının blog sayfasında bu defa istismar kodunun teknik detaylarına yer verildi.
Swift Changes.rtf dosyası çalıştırılır çalıştırılmaz Microsoft Office’in Microsoft Equation Editor bileşenindeki yığın tabanlı bellek taşması (stack buffer overflow) zafiyetini istismar ederek \\138.68.234.12\w\w.exe paylaşım adresi üzerinden w.exe dosyasını çalıştırıyordu. Şayet Windows, SMB protokolü üzerinden ilgili adrese bağlanamıyor ise ve işletim sistemi üzerinde WebClient servisi çalışır durumda ise bu durumda WebDAV protokolü üzerinden tanımlı vekil sunucu (proxy) ayarlarını da dikkate alarak bağlanmaya çalışmaktaydı. Bu durum da istismar edilen hedef sistemin ilgili adrese erişip zararlı kodu çalıştırma ihtimalini fazlasıyla arttırıyordu!
Son zamanlarda gerçekleştirilen siber saldırılarda zararlı RTF dosyalarının sıklıkla kullanılıyor olması sebebiyle bu yazı ile şüphe duyulan bir RTF dosyasının hızlı bir şekilde nasıl analiz edilebileceğine, Swift Changes.rtf dosyası özelinde yer vermek istedim. Zararlı RTF dosyalarının kötü emellerini gerçekleştirebilmeleri için OLE nesnelerinden faydalandıklarını bildiğimiz için Didier Stevens tarafından geliştirilen RTFDump aracı ile kısa bir sürede zararlı koda ulaşmak mümkün olabiliyor.
rtfdump aracına -aE parametresi vererek RTF içeriğini ASCII olarak görüntülediğimde ilgili OLE nesnelerini bulmak samanlıkla iğne aramaktan farksız olduğu için -f O parametresi ile sadece OLE nesnelerini listeledim. Ardından 7, 13, 19 ve 25 dizilerine tek tek -s ve -H (hex çıktısı) parametreleri ile baktığımda 7. dizide istismar kodu içine gömülü olan ip adresine ve Palo Alto Networks’un yazısına da konu olan WinExec fonksiyonunun adresine (0x430c12) statik olarak ulaştım.
Dinamik kod analizi ile de doğrulamak için ise öncelikle Windows Debugging Tools ile gelen Global Flags Editor üzerinde bir ayarlama yapmam gerekti. Swift Changes.rtf dosyası Microsoft Office Word ile açıldıktan sonra Microsoft Equation Editor bileşenine ait eqnedt32.exe programını istismar ettiği için eqnedt32.exe programı açılır açılmaz x64dbg hata ayıklayıcının devreye gireceği şekilde ayarladım. Winexec fonksiyonun adresine kesme noktası koyup adım adım geriye gidip fonksiyon çıkışlarına da kesme noktası koyarak kısa sürede ret2libc yönteminden faydalanan istismar koduna ulaşmış oldum.
Sonuç olarak siber saldırı girişimi, hazırlanan e-postanın tahminimce aceleye gelmesi (To: kısmında 952 kişinin olması, ileti gövdesinde metin olmaması vs.) ve sıfırıncı gün zafiyeti yerine genele duyurulan bir istismar kodunun (bu sayede güvenlik üreticileri imzalarını hızlıca güncelleyebildiler.) kullanılması sayesinde bildiğim kadarıyla Türkiye’deki herhangi bir bankada başarıya ulaşamadı. İstismar kodunun genele açık olarak yayınlanmasından 1 gün sonra bankalarımıza gerçekleştirilen bu siber saldırı bankalarımızı, finans kurumlarımızı hedef alan grupların ne kadar hızlı bir şekilde organize olup, hareket etmesi gelecekte benzer girişimlere, dikkat edilmesi gereken hususlara dair önemli ipuçları veriyor. Yazıma son noktayı koymadan önce bu ve benzeri siber saldırı girişimlerinin başarıya ulaşmasını zorlaştırma adına finans kurumlarının, iç ağdan internete doğru WebDAV kullanımını engellemelerinde fayda olacağına inanıyorum.
Bir sonraki yazıda görüşmek dileğiyle herkese güvenli günler dilerim.
Not: Kurum içinden internete doğru WebDAV bağlantısını kontrol etmek için Explorer üzerinden \\live.sysinternals.com adresine gitmeyi deneyebilirsiniz.
4 comments
5
Pratical reverse engineering’den başladım , ilginiz için teşekkür ederim hocam :)
Hocam reverse engineering konusunda kendimizi geliştirmek için nasıl bir roadmap önerirsiniz, sizce nasıl başlamalıyız.(Orta seviyede kod ve pentest bilgisi olan bir kişiye yönelik)
Assembly Language for x86 Processors (7th Edition), Secrets of Reverse Engineering, Practical Reverse Engineering, The Antivirus Hacker’s Handbook, Practical Malware Analysis bu alanda okunası faydalı kitaplar.