Kobold Mektupları: HTML e-postanın tehlikeleri
(lutrasecurity.com)Kobold Mektupları
- HTML e-postalarla teknik olarak uğraşmak zorunda olanlar, istemcilerin birbiriyle tutarsız uygulamaları yüzünden işlerini bırakmak ya da tüm posta istemcilerini ateşe vermek istemiş olacaklardır.
- HTML e-posta yalnızca bir can sıkıntısı kaynağı değil, aynı zamanda ciddi bir güvenlik riski de olabilir.
- Patronunuzun büyük miktarda para transfer etmenizi isteyen bir e-postayı size ilettiğini hayal edin; CEO dolandırıcılığı hakkında bir şeyler duyduğunuz için e-postanın gerçekten patronunuzdan gelip gelmediğini kontrol edersiniz.
- E-posta gerçekten patronunuzdan geliyordur ve şirketiniz böyle çalışıyorsa, hatta şifreli olarak imzalanmış bile olabilir.
- Ama yine de tam ikna olmaz, patronunuzu arayıp e-postanın gerçekliğini doğrularsınız.
- Patronunuz bunu onaylarsa parayı transfer edersiniz.
- Ama bu bir dolandırıcılık olmasaydı, bu makale burada biterdi.
Thunderbird
- Bu sorun 5 Mart 2024'te Mozilla'ya bildirildi ve planlanan yayın tarihiyle bir sonraki bölümün taslağı 20 Mart 2024'te Mozilla'ya iletildi.
- Olası hafifletme önlemleri tartışıldı, ancak ancak daha sonra uygulanması planlanıyor.
- Thunderbird'de bundan yararlanmak kolaydır. Thunderbird e-postayı `
` ile sarar ve bunun dışında değiştirmez.
- E-posta iletildiğinde, alıntılanan e-posta başka bir `
` ile sarılır ve DOM'da bir seviye aşağı taşınır.
- Bunu dikkate alınca aşağıdaki kavram kanıtı ortaya çıkar:
.kobold-letter {
display: none;
}
.moz-text-html>div>.kobold-letter {
display: block !important;
}
This text is always visible.
This text will only appear after forwarding.
- E-posta, her zaman görünen bir metin ile
display: none;kullanılarak gizlenen bir metin içerir. - E-posta iletildiğinde, gizli metin birdenbire yalnızca yeni alıcıya görünür hale gelir.
Outlook Web
- Bu sorun 5 Mart 2024'te Microsoft'a bildirildi ve planlanan yayın tarihiyle bir sonraki bölümün taslağı 20 Mart 2024'te Microsoft'a iletildi.
- Microsoft 26 Mart 2024'te hemen bir işlem yapmamaya karar verip raporu kapattı.
- Outlook Web'de (OWA) durum biraz daha karmaşıktır. E-posta `
` ile sarılır, ancak tam sınıf adı değişebilir.
- E-postanın CSS'inin webmail istemcisinin stillerini etkilememesi için Outlook, e-postadaki tüm id ve class adlarının başına
x_ekler ve CSS'yi buna göre ayarlar. - Bunu dikkate alınca aşağıdaki kavram kanıtı ortaya çıkar:
.kobold-letter {
display: none;
}
body>div>.kobold-letter {
display: block !important;
}
This text is always visible.
This text will only appear after forwarding.
- E-posta OWA'da görüntülendiğinde CSS şu şekilde görünür:
- E-posta iletildikten sonra Kobold mektubu bir başka `` ile sarılır ve CSS yeniden güncellenir.
Gmail
- Bu sorun 5 Mart 2024'te Google'a bildirildi ve planlanan yayın tarihiyle bir sonraki bölümün taslağı 20 Mart 2024'te Google'a iletildi.
- Gmail teknik olarak Kobold mektuplarına karşı savunmasız değildir. Çünkü e-posta iletilirken tüm stilleri kaldırır.
- Ancak CSS kaldırılmadan önce, CSS ile gizlenmiş Kobold mektubu otomatik olarak görünür hale gelir.
Önceki araştırmalar
- Bunun mümkün olması şaşırtıcı ya da yeni bir şey değildir.
- Geçmişte benzer sorunlar bildirilmişti.
Görünüm
- Kullanıcılar HTML e-postayı tamamen devre dışı bırakarak ya da kısıtlı modda görüntüleyerek Kobold mektuplarını hafifletebilir.
- E-posta istemcileri açısından bu hafifletmeleri uygulamak zordur. `` kullanımını engellemek sorunu çözebilir, ancak e-posta ekosisteminde zaten var olan birçok çözümü bozabilir.
- Ne yazık ki yakın gelecekte e-posta istemcilerinin sağlam hafifletmeler uygulamasını beklemek gerçekçi değildir.
GN⁺ görüşü
- Bu makale, HTML e-postanın zayıflıklarını gösteriyor ve özellikle e-posta iletildiğinde içeriğin değişebilmesine yol açan "Kobold mektubu" saldırısını açıklıyor. Bu, e-posta kullanıcılarında güvenlik farkındalığı oluşturabilecek önemli bir bilgi.
- E-posta istemcilerinin CSS'yi ele alma biçimine bağlı olarak güvenlik açıklarının ortaya çıkabileceğini gösteriyor ve hem kullanıcıları hem geliştiricileri güvenlik konusunda dikkatli olmaya çağırıyor.
- Bu tür saldırılar, kullanıcının güvendiği bir kaynaktan gelmiş gibi göründüğü için özellikle tehlikelidir. Bu da e-posta yoluyla iletişimde her zaman tetikte olma gereğini vurguluyor.
- Teknik açıdan bakıldığında, e-posta istemcisi geliştiricilerinin bu tür saldırıları önlemek için CSS işleme biçimlerini iyileştirmesi gerekiyor. Ancak bu, mevcut e-posta tasarımlarıyla uyumluluk sorunlarına yol açabilir; bu yüzden doğru dengeyi bulmak önemlidir.
- Bu makale yeni bir teknoloji ya da açık kaynak hakkında olmasa da, e-posta güvenliğiyle ilgili teknolojiler devreye alınırken dikkate alınması gereken noktaları ortaya koyuyor. E-posta istemcisi geliştiricileri, kullanıcı güvenliğini güçlendirirken kullanılabilirliği korumanın yollarını aramalıdır.
1 yorum
Hacker News görüşleri
The other day I was discussing the design for an "update" email that our designer was putting together...
I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...
The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...
Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?
HTML in email shouldn't be as big of a nightmare as it is.
Some possible mitigations from the top of my head (maybe ineffective):
When efail came out, I wrote a blogpost about the security risks of HTML mail.
This is really clever!