Kobold mektupları: HTML e-postanın tehlikeleri

• Kobold letters, HTML e-postanın ilk bakışta zararsız görünmesini, iletildikten sonra ise başka alıcılara phishing içeriğine dönüşmesini sağlayan bir saldırı tekniğidir
• Temel nokta, e-posta istemcilerinin izin verdiği CSS ile iletme sürecinde değişen DOM konumunu kullanarak belirli ifadeleri gizlemek veya yeniden göstermektir
• Thunderbird ve Outlook on the web’de, DOM yapısı ve CSS’i yeniden yazma biçimi nedeniyle iletildikten sonra gizli ifadeler görünebilir; Gmail’de ise iletme sırasında stillerin kaldırılmasıyla daha basit bir görünür hâle gelme mümkün olur
• Sorun 5 Mart 2024’te Mozilla, Microsoft ve Google’a bildirildi; Microsoft 26 Mart’ta acil bir işlem yapmadan raporu kapattı, Google ise 9 Nisan’da düzeltme üzerinde çalıştığını doğruladı
• Kullanıcılar HTML e-postayı kapatabilir veya kısıtlı modda görüntüleyebilir, ancak `` kullanımını engellemek mevcut e-posta ekosistemindeki birçok kullanım senaryosunu bozabileceği için istemci düzeyinde hafifletme kolay değildir

---

Saldırı senaryosu ve temel fikir

• Bir yöneticinin ilettiği e-posta başlangıçta zararsız bir talep e-postası gibi görünüp, iletildikten sonra yeni alıcı için phishing isteğine dönüşebilir
• Alıcı, gönderenin tanıdığı biri olması, bazı durumlarda kriptografik imza bile bulunması ve iletme gerçeğini telefonla doğrulasa dahi kandırılabilir
• Asıl alıcı olan yönetici, ilettiği e-postada phishing ifadesini görmediği için, iletme olayını doğrulasa bile saldırıyı fark etmesi zordur

Kobold letters nasıl çalışır?

• Çoğu e-posta istemcisi HTML e-postalarda CSS ile stillendirmeye izin verir
• Bir e-posta iletildiğinde, orijinal e-postanın DOM konumu genellikle değişir ve saldırgan bu değişime göre CSS seçicileri uygular
• Saldırgan, bağlama göre görünen veya kaybolan öğeleri e-postaya yerleştirebilir
  • Normalde display: none; ile gizler
  • İletildikten sonra DOM yapısı değiştiğinde display: block !important; gibi kurallarla gösterir
• Bu tür öğeler normalde görünmez, yalnızca belirli durumlarda ortaya çıkar ve phishing gibi amaçlarla kötüye kullanılabildiği için kobold letters olarak adlandırılır
• HTML e-postayı destekleyen e-posta istemcileri ve webmail hizmetlerinin geneli etkilenebilir

Thunderbird’deki davranış

• Thunderbird ile ilgili sorun 5 Mart 2024’te Mozilla’ya bildirildi; 20 Mart 2024 için planlanan açıklama tarihi ve taslak iletildi
• Olası hafifletmeler tartışıldı, ancak uygulamanın sonraya ertelenmesi bekleniyor
• Thunderbird e-postayı `

` ile sarar ve bunun dışında neredeyse hiç değiştirmez

• E-posta iletildiğinde alıntılanan orijinal e-posta yeniden `

` içine girer ve DOM’da bir seviye aşağı taşınır

• Örnek CSS, .kobold-letter öğesini varsayılan olarak gizler ve yalnızca .moz-text-html>div>.kobold-letter koşulunda gösterir
• Orijinal e-postayı gören kişiye yalnızca her zaman görünen paragraf gösterilirken, iletilmiş e-postayı alan kişiye gizlenmiş paragraf aniden görünür
• Saldırgan DOM içindeki göreli konumu bildiği ve CSS’i kontrol edebildiği için e-postanın bazı bölümlerini gizleyip göstererek tüm içeriği değiştirebilir
• Kobold letter bir katman gibi stillendirilirse, ileten kişinin orijinal e-postaya eklediği yorumları bile değiştirebilir; bu da phishing fırsatlarını artırır

Outlook on the web’deki davranış

• Outlook on the web sorunu 5 Mart 2024’te Microsoft’a bildirildi; 20 Mart 2024 için planlanan açıklama tarihi ve taslak iletildi
• Microsoft, 26 Mart 2024’te acil bir işlem yapmamaya karar verip raporu kapattı
• OWA webmail olduğu için durum daha karmaşıktır; e-posta `

` gibi bir konteynere yerleştirilir, ancak tam sınıf adı değişir

• Outlook, e-posta CSS’inin webmail arayüzü stillerini etkilememesi için id ve class adlarının başına x_ ekler ve CSS’i de buna göre ayarlar
• Örnekte, orijinal e-postanın CSS’i OWA’da görüntülenirken şu şekilde dönüştürülür
  • .rps_78fa .x_kobold-letter {display:none}
  • .rps_78fa > div > div > .x_kobold-letter {display:block!important}
• İletildikten sonra sınıf tekrar x_x_kobold-letter gibi değişir ve CSS de yeniden güncellenir
• İkinci kuralda .rps_78fa ile div arasındaki > kaybolduğundan, karmaşık seçiciler oluştururken bunun dikkate alınması gerekir
• OWA’nın bu düzenlemesi saldırının kendisini engellemez; ancak birden fazla istemcide aynı anda çalışan kobold letter oluştururken zahmetli bir kısıta dönüşür

Gmail’deki davranış

• Gmail sorunu 5 Mart 2024’te Google’a bildirildi; 20 Mart 2024 için planlanan açıklama tarihi ve taslak iletildi
• Google, 9 Nisan 2024’te düzeltme üzerinde çalıştığını doğruladı
• Gmail, e-postayı iletirken tüm stilleri kaldırdığı için, CSS seçicileriyle görünürlüğün bağlama göre değiştirildiği dar tanımdaki kobold letters’a teknik olarak açık değildir
• Ancak daha basit bir saldırı mümkündür
  • Orijinal e-postada kobold letter’ı CSS ile gizlemek
  • İletme sırasında stiller kaldırılınca gizli öğenin otomatik olarak görünmesi
• Bu yöntem sınırlıdır; orijinalde görünen ve iletildikten sonra kaybolan ters davranış yapılamaz
• Gmail, e-postayı göndermeden önceki düzenleyicide CSS’i henüz kaldırmadığı için, ileten kişi yorum yazarken de gizli paragrafı görmez
• Sonuç e-postada stiller kaldırılır ve ikinci paragraf görünür
• Gmail CSS’i düzenleyici aşamasında kaldırırsa, ileten kişi göndermeden önce saldırıyı fark edebilir ve sorun hafifletilebilir

Önceki benzer örnekler ve farklar

• HTML e-postada CSS ile yanıt/iletme içeriğinin değişebilmesi yeni değildir
• Geçmişte benzer sorunlar da raporlandı
  • Thunderbird - Modification of replied mail content without knowledge of replier of the mail using CSS
  • Treat OpenPGP/SMIME email messages with certain CSS elements as unsigned
  • Composition should use inline styling so that styles from quotes don’t leak into the message
• Kobold letters’ın farkı, belirli bir saldırı senaryosuna odaklanması ve birden fazla e-posta istemcisini birlikte incelemesidir
• HTML e-postanın riskleri ve bunları hafifletmek için gereken ödünleşimler üzerine tartışma gereklidir

Hafifletmeler ve sınırlar

• Kullanıcılar HTML e-postayı tamamen devre dışı bırakabilir veya Thunderbird’deki “plain HTML” gibi kısıtlı modlarda görüntüleyebilir
• E-posta istemcisi `` kullanımını engellerse sorun çözülebilir, ancak e-posta ekosistemindeki mevcut birçok kullanım senaryosu bozulabilir
• Gmail gibi iletme sırasında stilleri kaldıran bir uygulama, stilli kurumsal bültenlere izin verirken HTML e-posta risklerini sınırlayan bir uzlaşma olabilir
• Yakın gelecekte e-posta istemcilerinin güçlü hafifletmeler uygulamasını beklemek gerçekçi değildir
• Kullanıcılar HTML e-postanın risklerinin farkında olmalı ve gerekli önlemleri kendileri almalıdır

[GN⁺]

Hacker News yorumları

• “Yine de emin olamadığı için yöneticiye telefon edip e-postanın gerçek olup olmadığını doğrular. Yönetici doğru olduğunu söyleyince parayı gönderir” kısmı çok büyük bir varsayım gibi geliyor
  Genelde “Bu e-postayı siz mi gönderdiniz?” gibi muğlak sormaktansa “Gerçekten parayı bu şekilde göndermemi mi istiyorsunuz?” diye daha somut sorulur; o zaman yönetici doğal olarak şaşırır ve saldırının o konuşmada engellenme ihtimali yüksek olur
  İlginç bir saldırı yolu, ama gerçek başarı olasılığı şüpheli. Yazı, bu saldırının işlemesi için oldukça belirli ve dar bir olay akışı gerektiğini çiziyor; kişisel olarak pek ikna edici bulmuyorum
  Kimlik avının gerçekten işe yaradığını biliyorum. Ancak kimlik avına kanacak kişiler için bu kadar incelikli bir saldırıya gerek yok; hatta saldırgan böyle çok spesifik bir çaba harcarsa başarı olasılığını daraltabilir. Sıradan bir phishing e-postasının bile başarılı olma ihtimali yüksek

  • 10 bin çalışanı olan, yarısı mühendislerden oluşan bir şirkette çalıştım; her yıl birkaç kez birilerinin “CEO” ya da başka bir üst düzey yönetici için şirket kartıyla hediye kartı satın aldığı olurdu
    Bu yöneticilerin bilgileri LinkedIn’de ya da şirket sitesinde kolayca bulunabiliyordu; hatta bu örnekler phishing karşıtı eğitimin birebir örnekleriydi, buna rağmen yaşanması şaşırtıcı olabilir
  • Aslında tam tersine daha yakın. En bariz ve gülünç dolandırıcılıkların en iyi işlediği iyi belgelenmiş bir gerçek; çünkü en kolay kandırılacak olası kurbanları elemenin en iyi yolu bu
    https://www.microsoft.com/en-us/research/publication/why-do-...
  • Kişiye göre değişir gibi. Bazı yöneticiler gün içinde defalarca bu tür ödemeleri onaylamak zorunda kaldığı için böyle konuşmaları can sıkıcı bulabilir; çalışanlar da bu konuşmalardan kaçınmak isteyebilir
    Saldırgan “Şu anda iş seyahatindeyim. Emin değilseniz kişisel cep telefonumdan arayın...” gibi bir ifade ekleyip ardından sahte sesle yanıt verebilir
    Hedefe ulaşmanın iyi bir yolu “çift iletme” olabilir. Gönderen, yöneticinin e-postasını idari işlerden sorumlu kişinin yakınındaki bir çalışana ileten çalışan rolüne girer; o çalışan da doğum günü kutlaması ya da hastalık izni bildirimi gibi görünüşte zararsız bir nedenle e-postayı tekrar iletirse, asıl hedef e-postanın gerçek kaynağını anlamakta zorlanır
    Bunun dışında bu “özelliği” daha yaratıcı biçimlerde kötüye kullanmanın yolları da kolayca akla geliyor. Örneğin hiçbir şeyden haberi olmayan birinin sorunlu bir içeriği iletmesini sağlayıp sonra şantaj yapmak da mümkün
  • Büyük bir şirketin borç hesapları departmanına böyle bir e-posta gönderildiği bir durumda bu çok da gerçek dışı olmayabilir
    Ödeme talepleri e-postayla geldiğinde görevliler her seferinde hat yöneticisini aramayacaktır; özellikle tutar küçükse ve ön onay gerekmiyorsa daha da öyle
    Google’ın da ortada gerçek bir iş yokken birine ödeme yaptığı bir dolandırıcılığa uğradığını hatırlıyorum. O vakada sahte fatura vardı ama prensip aynı
  • Teorik olarak havalenin alıcı bilgisini değiştirme gibi daha incelikli ve hedefli saldırıları mümkün kılabilir. Bu tür saldırıları tespit etmek çok daha zordur

• Birkaç gün önce bir tasarımcının hazırladığı “güncelleme” e-posta tasarımına bakıyordum; en üste koyduğu saçma derecede büyük grafik başlık yüzünden kaydırmadan e-postanın başlık metni bile görünmüyordu
  Sonra geri bildirim istemek için başka bir sürümü iletti; birden yazı tipi biraz küçülmüş gibi görünüyor diye şaşırdı ve “Aa, iletince mobil sürüm değil masaüstü sürüme dönüşüyor!” dedi
  Bunu duyunca inanamayarak boş boş baktım. Bu bir e-posta; “masaüstü sürüm” ve “mobil sürüm” ne demek? Böyle bir şey nasıl mümkün oluyor? “Dönüşüyor” ne demek? Sadece kopyalanıyor işte. İletildiğinde “bozuluyor” olması bile bu yöntemin ne kadar aptalca olduğunu gösteriyor. Benim e-postamda CSS’in ne işi var?
  İtalik gibi şeyleri ifade etmek için Markdown gibi çok daha basit bir yaklaşım benimsenmeliydi; hâlâ bunun yapılmamış olması akıl alır gibi değil. Bu durum, bunu gerçekten iyileştirmeye ilginin ne kadar az olduğunu gösteriyor. Hepsi logoları ve banner’ları her yere koymak isteyen tuhaf kurumsal talepleri karşılamak için. HTML e-posta gerçekten saçmalık

  • Yalnızca italik vb. ifade etmek istiyorsanız, 1996’da çıkan text/enriched [1] aradığınız şey gibi duruyor. Neredeyse tüm e-posta istemcilerinin okuma desteği sunma ihtimali yüksek
    [1] https://www.rfc-editor.org/rfc/rfc1896.txt
  • MJML gibi responsive e-posta framework’leri gerçekten var

• E-postada zengin metin için HTML yerine, Markdown’dan inline HTML çıkarılmış hâli ya da benzeri basit bir metin işaretleme dili kullanılması gerektiğini uzun zamandır savunuyorum
  Böylece e-posta istemcisi bunu zengin metin olarak mı, yoksa düz metin olarak mı göstereceğine kolayca karar verebilir; normal kullanıcıların ihtiyaç duyduğu biçimlendirmelerin çoğunu da destekleyebilir: kalın, italik, alıntı, inline görsel, kod blokları, başlıklar vb.
  Çok gelişmiş HTML kullanan pazarlama e-postaları için iyi olmazdı ama böyle kullanım örneklerini önemsememiz gerektiğini düşünmüyorum

  • Benzeri olarak RFC 1896’da tanımlanan text/enriched var. Apple Mail gibi istemciler de destekliyor
    https://en.wikipedia.org/wiki/Enriched_text
    https://www.rfc-editor.org/rfc/rfc1896.html
  • Birçok Markdown parser’ı inline HTML’e izin veriyor. Bazı dillerde çoğu böyle; kapatmaya izin veren parser sayısı ise az. Gerçekten aptalca
  • Lynx tarayıcısı gibi metin terminalinde HTML gösterme yöntemi de epey iyi çalışıyor; neden illa başka bir işaretleme dili gerektiğini anlamıyorum
  • Yeterli benimsenme elde etmek zor. Çünkü e-posta standartlarını değiştirmek zor
    E-postada hâlâ hyperlink koyma desteği bile yok ve yakın zamanda bunu düzeltmeye çalıştılar
    https://pastebin.com/kHQs50xm
  • Renk ve boyut, yazının temel ve faydalı unsurlarıdır

• Kuruluş için asıl risk, HTML e-posta üretmekle görevlendirilen geliştiricinin kafayı yiyip sunucu odasına kapanması ve “Outlook render’ı neden farklı çıkıyor?” diye bağırarak tüm donanımı parçalamasıdır.
  Tabii ciddi konuşmak gerekirse, bu çok ilginç bir zafiyet.

  • Bu yüzden birkaç yıldır e-postayla ilgili işleri doğrudan HTML e-posta kodlama hizmetlerine para vererek yaptırmaya karar verdik. Litmus testini geçen HTML şablonları kodlamak çok özel bilgi gerektiriyor ve bir daha o işe girmek istemiyorum.

• Stil sayfalarına izin vermeyip yalnızca etiketlerin inline style özniteliklerine izin vererek düzeltilemez mi?
  Kullanılabilirlik için e-posta istemcisi, tüm stil sayfalarını inline stillere “derleyen” otomatik bir adım da ekleyebilir.
  Böyle olursa yalnızca hover gibi gelişmiş CSS seçicileri bozulur; onların gerçekten gerekli olup olmadığından pek emin değilim.

  • Katılıyorum. Mesajı göstermeden önce tüm sınıfları inline style olarak içine gömmek sorunu çözer gibi. Zaten mantıklı olan da bu.
    Sözde sınıflar ve medya sorguları çalışmaz, ama bunlar güvenlik riski olabilir ve başlıca e-posta istemcilerinde de desteklenmiyor: https://www.caniemail.com/features/css-at-media/
  • Outlook ve Gmail onlarca yıllık render motorları kullandığı için HTML e-postalarda CSS’i zaten inline hâle getirmeniz gerekir. Outlook kelimenin tam anlamıyla 2006 civarından kalma MS Word HTML motorunu kullanıyor.
    Üstelik tüm style özniteliklerini öldürürseniz mobil optimizasyonu ve karanlık modu da öldürmüş olursunuz. Çünkü medya sorguları inline hâle getirilemez.
  • O zaman mevcut responsive e-posta yaklaşımı da bozulur.
    Genellikle temel/masaüstü stiller zaten derlenip inline hâle getirilir; mobil cihazlarda okunması kolay olsun diye head içindeki style etiketinde medya sorgusu seçicileri tutulur.

• Gerçekten zekice.
  Varsayım şu: HTML e-postadaki CSS yüzünden bazı metinler ancak mesaj iletildikten sonra görünür hâle gelebiliyor. Bu, doğrulanmış e-postanın güvenilirliği için büyük bir tehdit.
  Thunderbird, Outlook ve Gmail örnekleri verilmiş; çok iyi iş çıkarılmış.
  Ben tüm e-postalarımı mutt’ta okuduğum için resmen “başkasının sorunu” diyorum.
  Bu yüzden başka bir şeyden şikâyet edecek olursam: Mozilla’ya rapor edildiği tarih 05.03.2024 olarak yazılmış. Little-endian tarihlerin Amerikan tarzı middle-endian tarihlerden daha mantıklı olduğuna katılıyorum.
  Ama bir teknoloji insanı olarak ISO 8601 tarih biçimi olan 2024-03-05’i, tireli ya da tiresiz, kullanmamanın yanlış olduğunu düşünüyorum :)

  • Sadece bu da değil; middle-endian tarih biçimini kullanan herkes yanlış yapıyor. Bir şeyi yazma biçimleri içinde en irrasyonel olanı bu.
    Little-endian en azından diğer tüm sayıları yazma biçimimizin tersi olma erdemine sahip; middle-endian ise düpedüz akıl dışı. Tabii bu yüzden Amerikalıların kullandığı biçim de o.

• Bahsedilen bazı e-posta istemcilerinin posta içeriğini ek HTML etiketleriyle sardığı ve CSS ile sınıf adlarını değiştirdiği görülüyor.
  E-posta istemcileri HTML e-postaları render ederken neden sandbox iframe kullanmıyor, merak ediyorum. Hâlâ bir güvenlik riski mi var?

  • Ek HTML, iletilen e-postayı okuyan istemcide oluşmuyor; iletme sırasında oluşuyor.
    İleten kişi e-postaya daha fazla metin eklemek isteyebileceğinden bu beklenen bir davranış.
  • Eskiden iframe kullanıyorduk ve sorunlar vardı. Render ya da güvenlik sorunu değildi; hatırladığım kadarıyla o taraf gayet iyi çalışıyordu.
    Ancak e-postada bir web sitesi bağlantısı varsa ve sandbox iframe JavaScript’e izin vermiyorsa, o güvenlik bağlamı iframe içindeki bağlantıya tıklanarak açılan sayfaya kadar taşınıyor ve web sitesi JS kullanamıyordu.
    Çözüm allow-popups-to-escape-sandbox idi; bu yüzden artık çalışmaması için bir neden görünmüyor.

• Yarayı iyileştireceğim diye kolu bacağı kesen tipik bir çözüm. Sorun, bu tür hack’lerin egemen olmasına izin veren e-posta standardizasyonunun zayıflığı.
  HTML genel olarak bu tür endişelere açık. Yine de HTML kullanan ve sorunsuz çalışan çok e-posta var. Bu yazı, sahada karşılaşılan bir şeye dair kişisel hayal kırıklığını güvenlik sorunu gibi paketlemiş izlenimi veriyor.

• Aklıma gelen olası hafifletmeler şunlar, ama etkili olmayabilir: gizli öğeler için göze çarpan uyarılar göstermek, alıcı ve gönderici tarafında sarmalayan div sayısını rastgeleleştirmek, iletme sırasında gerçekte nasıl görüneceğini hesaplayıp büyük fark varsa onay istemek.
  Ya da ters yönde işlem yapmak daha etkili olabilir; çünkü diğer istemcilerin yardımını gerektirmez.

• “E-posta neden kuruluşlar için risklidir?” diye düzeltmek yeterli.

  • O noktada bu, sadece “Dış dünyayla iletişim neden kuruluşlar için risklidir?” olur.
    Bu yazı HTML e-postaya özgü bir saldırı yolu gösteriyor, ama e-posta üzerinden yapılan saldırıların çoğu WhatsApp, Slack, Jira, Zoom ya da insanların dış dünyayla iletişim kurduğu herhangi bir araca kolayca taşınabilir.