Metadata, Azure Frontable Domain Tespiti, Office Belgelerindeki Tehdit

Metadata Candır!

Saldırgan için bir sistemin topografisini çıkartmak, işinin en önemli adımlarından biridir. Böylece zincirdeki en zayıf halka tespit edilip, sistemin tamamına erişim sağlamanın yolları aranır.

Bu elbette ki yazıldığı kadar kolay olmayan bir aşama. Açık kaynaklardan veriler ya da port scanning gibi pek çok adım ile toplanan verilerden elde edilen sonuçlar sayesinde sisteme dair bir topolojik harita çıkartılabiliyor.

Sistem kullanıcılarının paylaştığı dosyalar ise bazen bu adımların tümünün zahmetini ortadan kaldıracak bilgileri ifşa edebiliyor: Metadatalar

Metadata, bilgiyi tanımlayan bilgi olarak özetleyebileceğimiz bir kavram. İnternet üzerinden paylaşılan dosyalara, bu dosyaların oluşturulma, düzenlenme hatta yazdırılma aşamalarında eklenen bu küçük bilgi parçaları, sistem hakkında önemli bilgiler ifşa edebilen noktalar barındırıyor.

Metadata kimi zaman dosyanın oluşturulduğu düzenlendiği programın isim ve sürümünü ihtiva ederken, kimi zaman dosyanın oluşturulduğu ya da son erişildiği tarihi; kimi zaman ise belgenin oluşturulduğu işletim sisteminden, bu işletim sistemindeki hangi kullanıcı tarafından oluşturulup/düzenlendiğine kadar sıralanabilecek hassas bilgileri ifşa eder.

Bundan ne çıkar, diye düşünülüyor olabilir. Oysa sistemde güncelliğini yitirmiş ve zafiyet içeren bir program kullanılıp kullanılmadığına, hangi donanımların mevcut olduğuna, sistemde hangi kullanıcıların olduğuna dair pek çok bilgiye saldırgan tarafından üstelik bir kerede erişilebilir.

*Nix tabanlı işletim sistemlerinde tüm web sitesinin bir mirror'ını oluşturmak için, örneğin:

wget -mk http://www.example.com

Yukarıdaki -m parametresi tüm siteyi download ederken -k parametresi sayesinde kendi dosya sisteminizde bu dosyalar arasındaki bağlantıların kurulması, yani hyper linklerin dosya sistemi linklerine dönüştürülmesi için kullanılabilir.

Wget metodu ile uzantısı ne olursa olsun tüm dosyalar indirilecektir. Oysa arama motorları vasıtası ile daha spesifik bir dosya türü için arama yapabilirsiniz:

filetype: pdf site:netsparker.com

Bunun için kullanabileceğiniz pek çok komut seti, hatta hazır program var. Ama meselenin sızma testi açısından ifade ettiği anlam ile ilgili güzel bir yazı okumak isterseniz Sweepatic blogunda yayınlanan Metadata: A Hacker`s Best Friend yazısına göz atabilirsiniz.

Dosyalarınızdaki metadataları temizlemek için ise, MAT (Metadata Anonymisation Toolkit) kütüphanesini dosyaları yayınlanmadan önce kullanmanızı tavsiye ederiz.

Azure Frontable Domainlerini Tespit Etmek

Aşina olmayanlar için fronting teknolojisini özetleyecek olursak, gelen istekleri karşılayarak, Host header bilgisi üzerinden ilgili CDN ile map eden teknolojiler diyebiliriz.

Tarayıcımızın adres çubuğuna www.example.com yazıp enter tuşuna bastığımızda yapılan ilk iş www.example.com 'u barındıran sunucunun IP adresini çözümlenmesi. DNS protokolü ile yapılan bu operasyon ile birlikte sunucunun IP adresine tarayıcı tarafından hazırlanan HTTP paketi gönderilir.

Peki ya www.example.com 'u barındıran sunucu birden fazla siteyi barındırıyorsa? İşte bu durumda ortaya çıkacak keşmekeşin önü, HTTP 1.0+'dan itibaren (HTTP 1.1'den itibaren ise zorunlu olarak) Host headerı ile alınıyor. www.example.com 'u barındıran sunucuya HTTP paketi gönderilirken, bu sitede barındırılan herhangi bir site için değil, www.example.com için bu isteğin yapıldığı da Host headerı ile belirtiliyor.

GET / HTTP/1.1
Host: www.example.com

Burada ilgi çekici olan şu, DNS çözümlenmesinde www.example.com 'un gözükmesi.

Pekala www.example.com 'u çözümleyen sunucuda başka bir domain için de site barındırılıyor olabilirdi.

GET / HTTP/1.1
Host: www.anothersite.com

Network seviyesindeki bir gözlem için www.example.com 'a ulaştığımız algısı oluşuyor.

Peki buradan hareketle domain'imizi yüksek değere, yani meşruiyete sahip bir domain ile ilişkilendirebilir miyiz?

Tabii ki evet. Finding Domain frontable Azure domains yazısı ile Azure CDN ile kullanabilecek domainlerin nasıl tespit edildiği anlatılıyor.

Yüksek seviyeli olarak tabir edilen fakat bizim meşruiyet kat sayısı diye tercüme ettiğimiz vakıa sayesinde Signal'in erişimlerinin engellendiği Mısır örneğinde gördüğümüz gibi sansürleri atlatabilmek mümkün. Bunun teknik arkaplanı için Host Of Troubles araştırmasına da bakılabilir.

Nitekim bu akademik araştırmada da yine Host headerı marifeti ile nasıl Windows'daki parental kontrollerin aşılabileceğine dair bir örnek söz konusu.

Devam edecek olursak, Azure CDN'ine endpoint kaydı yaptırdığımızda bize domainimiz ile ilişkilendirilecek bir domain tahsis ediliyor. (2legit2quit.azureedge.net).

2legit2quit.azuredge.net adresine yapılan bir istek, blog posttaki örneğe istinaden, theobsidiantower.com'a yönlendirilecek. Meşruiyet katsayısı yüksek domainler dedik ama karşımızda sadece azureedge.net domaini var. Pek çoğumuzun ilk defa duyduğu bir domain.

Yazar makalenin devamında Censys.io üzerinden azureedge.net domaini ile ilişkili sertifikaları, buradan hareketle de domainleri sorguluyor:

https://censys.io/certificates?q=parsed.names:%20azureedge.net

Censys.io web sayfası üzerinden üzerinden yapılacak sorgular günlük 25 sorgu ile kısıtlanmış durumda. Araştırmasına Censys.io API ile devam eden yazar, azureedge.net ile ilişkilenmiş sertifikaya sahip 2150 domain tespit ediyor.

Buradan hareketle, yüksek tanınırlığa sahip domainleri eleyen yazar, Microsoft ile ilgili örneğin aşağıdaki domainlere erişiyor:

# cat known-good.txt | grep microsoft | grep -v goskope
*.Applicationinsights.microsoft.com
*.manage.microsoft.com
*.media.microsoftstream.com
*.microsoft-sbs-domains.com
*.microsoft.com
*.mp.microsoft.com
*.s.windows.microsoft.com
ajax.microsoft.com
cdn.wallet.microsoft-ppe.com
cdn.wallet.microsoft.com
download.learningdownloadcenter.microsoft.com
download.visualstudio.microsoft.com
lumiahelptipscdn.microsoft.com
lumiahelptipscdnqa.microsoft.com
lumiahelptipsmscdn.microsoft.com
lumiahelptipsmscdnqa.microsoft.com
mscrl.microsoft.com
r20swj13mr.microsoft.com
software-download.coem.microsoft.com
software-download.microsoft.com
Software-download.office.microsoft.com

Skype ile ilgili olarak ise:

# cat known-good.txt | grep skype | grep -v goskope
*.cdn.skype.com
*.cdn.skype.net
*.dev.skype.com
*.secure.skypeassets.com
*.secure.skypeassets.net
do.skype.com

Görüldüğü üzere do.skype.com ve ajax.microsoft.com aynı IP adresini çözümlüyor. Azure'da oluşturulan adres de Host headerı marifetiyle gönderildiğinde bu iki domain kullanılarak kendi sitemize erişebilmek mümkün olacak. Böylece aradaki pek çok filtre bypass edilebilecek.

http://ajax.microsoft.com

GET / HTTP/1.1
Host: 2legit2quit.azuredge.net

Ayrıntılı bilgi için araştırmanın bulunduğu blog yazısına müracaat edebilirsiniz.

Office Belgesi Deyip Geçmeyin! Kritik Altyapılar Tehdit Altında!

Zararlı makrolar içeren ofis belgelerinin eposta yoluyla dolaşıma sokulduğu ve pek çok sistemin bu dosyalar nedeniyle Ransomware vb saldırılara maruz kalmasının haber değeri bile kalmadı.

Ama bu defa durum biraz farklı. Tüm koruma tedbirlerini atlatabilen, hiçbir zararlı makro içermeyen, suret-i haktan görünen ofis belgeleri bilgilerinizi çalmak için kullanılabilir.

Genellikle çevre raporu veya CV görünümünde eposta kutunuza düşen ofis belgelerinden söz ediyoruz. Tıpkı son zamanlarda enerji sektörünü hedef alan türevleri gibi.

Cisco Talos Security'nin ayrıntılarını paylaştığı vakaya göre CV görünümündeki ofis belgeleri uzak bir SMB sunucusundan Word template'i yüklemeye çalışarak, kurban makinesinden oturum bilglerini elde etmeyi deniyor.

Phishery kütüphanesi bu konuda örnek bir dizi kod sunuyor. Talos 'un analiz ettiği doküman ise biraz daha güncellenmiş ve SMB kullanan version. Phishery sadece Basic authentication response'u vererek kullanıcının karşısına bir kullanıcı adı parola ekranı çıkartıyor idi.

Ekran görüntüsünden de anlaşılacağı üzere Word belgesi açılırken Template.dotm isimli bir dosyayı uzak bir sunucudan indirmeye çalışılıyor.

Ayrıntılar için ilgili makaleye müracaat edebilirsiniz.