Surat Kobold: Bahaya Email HTML

• Kobold letters adalah teknik serangan yang membuat email HTML awalnya tampak tidak berbahaya, lalu berubah menjadi konten phishing bagi penerima lain setelah diteruskan
• Intinya adalah memanfaatkan CSS yang diizinkan klien email, serta perubahan posisi DOM saat proses penerusan, untuk menyembunyikan atau menampilkan kembali frasa tertentu
• Thunderbird dan Outlook on the web dapat menampilkan frasa tersembunyi setelah diteruskan karena struktur DOM dan cara penulisan ulang CSS, sementara Gmail memungkinkan bentuk paparan yang lebih sederhana karena menghapus style saat penerusan
• Masalah ini dilaporkan ke Mozilla, Microsoft, dan Google pada 5 Maret 2024; Microsoft menutupnya pada 26 Maret tanpa tindakan langsung, dan Google mengonfirmasi pada 9 April bahwa perbaikan sedang dikerjakan
• Pengguna dapat mematikan email HTML atau melihatnya dalam mode terbatas, tetapi memblokir `` dapat merusak banyak kasus penggunaan yang sudah ada di ekosistem email, sehingga mitigasi di tingkat klien tidak mudah

---

Skenario serangan dan ide utamanya

• Email yang diteruskan oleh admin awalnya bisa terlihat seperti email pertanyaan yang tidak berbahaya, tetapi setelah diteruskan dapat berubah menjadi permintaan phishing bagi penerima baru
• Penerima melihat pengirimnya sebagai orang yang dikenal, kadang bahkan dengan tanda tangan kriptografis, dan bisa tetap tertipu meski sudah mengonfirmasi lewat telepon bahwa email memang diteruskan
• Karena admin sebagai penerima awal tidak pernah melihat frasa phishing di email yang ia teruskan, ia pun sulit menyadari adanya serangan meski mengonfirmasi bahwa ia memang meneruskannya

Cara kerja Kobold letters

• Sebagian besar klien email mengizinkan styling CSS di dalam email HTML
• Saat email diteruskan, posisi DOM dari email asli biasanya berubah, dan penyerang menerapkan selector CSS berdasarkan perubahan itu
• Penyerang dapat menyisipkan elemen yang muncul atau hilang tergantung konteks di dalam email
  • Biasanya disembunyikan dengan display: none;
  • Setelah diteruskan, saat struktur DOM berubah, elemen ditampilkan dengan aturan seperti display: block !important;
• Elemen semacam ini biasanya tidak terlihat lalu hanya muncul dalam situasi tertentu, dan karena dapat disalahgunakan untuk phishing, disebut kobold letters
• Klien email dan webmail yang mendukung email HTML secara umum dapat terdampak

Perilaku di Thunderbird

• Masalah terkait Thunderbird dilaporkan ke Mozilla pada 5 Maret 2024, lalu draf dan tanggal rencana publikasi 20 Maret 2024 disampaikan
• Beberapa mitigasi yang mungkin sempat dibahas, tetapi implementasinya dijadwalkan untuk nanti
• Thunderbird membungkus email dengan `

`, dan selain itu hampir tidak mengubah apa pun

• Saat email diteruskan, email asli yang dikutip kembali dimasukkan ke dalam `

` sehingga berpindah satu tingkat lebih dalam di DOM

• Contoh CSS menyembunyikan .kobold-letter secara default, lalu hanya menampilkannya pada kondisi .moz-text-html>div>.kobold-letter
• Bagi orang yang melihat email asli, hanya paragraf yang memang selalu terlihat yang tampil, tetapi bagi penerima email yang diteruskan, paragraf yang tadinya tersembunyi tiba-tiba muncul
• Karena penyerang mengetahui posisi relatif di dalam DOM dan dapat mengendalikan CSS, ia bisa menyembunyikan atau menampilkan bagian email untuk mengubah seluruh isi pesan
• Jika kobold letter diberi style seperti overlay, komentar tambahan yang ditulis penerus di email asli pun dapat digantikan, sehingga peluang phishing makin besar

Perilaku di Outlook on the web

• Masalah di Outlook on the web dilaporkan ke Microsoft pada 5 Maret 2024, lalu draf dan tanggal rencana publikasi 20 Maret 2024 disampaikan
• Microsoft memutuskan pada 26 Maret 2024 untuk tidak mengambil tindakan segera dan menutup laporan tersebut
• Karena OWA adalah webmail, situasinya lebih rumit; email memang dimasukkan ke dalam kontainer seperti `

`, tetapi nama class yang tepat berubah

• Outlook menambahkan prefiks x_ pada id dan class, lalu menyesuaikan CSS juga, agar CSS email tidak memengaruhi style antarmuka webmail
• Dalam contoh, CSS email asli diubah saat ditampilkan di OWA menjadi seperti berikut
  • .rps_78fa .x_kobold-letter {display:none}
  • .rps_78fa > div > div > .x_kobold-letter {display:block!important}
• Setelah diteruskan, class kembali berubah menjadi seperti x_x_kobold-letter dan CSS juga diperbarui lagi
• Pada aturan kedua, > di antara .rps_78fa dan div menghilang, jadi hal ini perlu diperhitungkan saat membuat selector yang kompleks
• Penyesuaian OWA tidak menghentikan serangan itu sendiri, tetapi menjadi kendala yang merepotkan saat membuat kobold letter yang bisa berjalan serempak di beberapa klien

Perilaku di Gmail

• Masalah di Gmail dilaporkan ke Google pada 5 Maret 2024, lalu draf dan tanggal rencana publikasi 20 Maret 2024 disampaikan
• Google mengonfirmasi pada 9 April 2024 bahwa perbaikan sedang dikerjakan
• Gmail menghapus semua style saat meneruskan email, sehingga secara teknis tidak rentan terhadap definisi sempit kobold letters yang mengubah visibilitas berdasarkan konteks menggunakan selector CSS
• Namun, serangan yang lebih sederhana tetap dimungkinkan
  • Sembunyikan kobold letter di email asli dengan CSS
  • Saat diteruskan, style dihapus sehingga elemen tersembunyi otomatis tampil
• Pendekatan ini terbatas, dan tidak bisa melakukan kebalikan, yaitu terlihat di email asli lalu menghilang setelah diteruskan
• Karena Gmail belum menghapus CSS di editor sebelum email dikirim, paragraf tersembunyi tetap tidak terlihat saat penerus sedang menulis komentar
• Di email hasil akhirnya, style dihapus sehingga paragraf kedua muncul
• Jika Gmail menghapus CSS sejak tahap editor, penerus dapat menemukan serangan sebelum menekan kirim sehingga dampaknya bisa dikurangi

Kasus serupa sebelumnya dan perbedaannya

• Bahwa CSS di email HTML dapat mengubah konten balasan atau penerusan bukanlah hal baru
• Masalah serupa juga pernah dilaporkan sebelumnya
  • 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
• Perbedaan Kobold letters adalah fokusnya pada skenario serangan tertentu dan meninjau beberapa klien email sekaligus
• Perlu ada pembahasan mengenai bahaya email HTML dan trade-off untuk memitigasinya

Mitigasi dan keterbatasannya

• Pengguna dapat menonaktifkan email HTML sepenuhnya atau melihatnya dalam mode terbatas seperti “plain HTML” di Thunderbird
• Klien email bisa menyelesaikan masalah ini dengan memblokir penggunaan ``, tetapi banyak kasus penggunaan yang sudah ada di ekosistem email bisa rusak karenanya
• Implementasi seperti Gmail yang menghapus style saat penerusan dapat menjadi kompromi yang membatasi risiko email HTML sambil tetap mengizinkan newsletter perusahaan yang bergaya
• Tidak realistis berharap klien email akan menerapkan mitigasi yang kuat dalam waktu dekat
• Pengguna perlu menyadari bahaya email HTML dan mengambil langkah pencegahan yang diperlukan sendiri

[GN⁺]

Komentar Hacker News

• Bagian “meski begitu, karena masih belum yakin, ia menelepon manajer untuk memastikan apakah email itu asli. Setelah manajer bilang benar, ia mentransfer uang” terasa seperti asumsi yang terlalu besar
  Biasanya orang tidak akan bertanya samar seperti “Apakah Anda mengirim email ini?”, melainkan lebih spesifik, “Apakah benar Anda meminta saya mentransfer uang dengan cara seperti ini?”; kalau begitu, manajer tentu akan bingung dan besar kemungkinan serangan itu berhenti di percakapan tersebut
  Ini memang jalur serangan yang menarik, tetapi peluang keberhasilan nyatanya patut dipertanyakan. Tulisan itu menggambarkan bahwa agar serangan ini berhasil, dibutuhkan alur kejadian yang cukup spesifik dan sempit, dan secara pribadi saya kurang bisa menerimanya
  Saya tahu phishing memang berhasil di dunia nyata. Namun orang-orang yang akan terkena phishing biasanya tidak membutuhkan serangan secanggih ini, dan justru jika penyerang mengerahkan upaya yang sangat spesifik seperti ini, peluang keberhasilannya bisa makin menyempit. Email phishing biasa saja sudah besar kemungkinan berhasil

  • Saya pernah bekerja di perusahaan dengan 10.000 karyawan, separuhnya engineer, dan setiap tahun selalu ada beberapa kasus seseorang membeli kartu hadiah dengan kartu perusahaan untuk “CEO” atau eksekutif senior lain
    Informasi para eksekutif itu mudah ditemukan di LinkedIn atau situs perusahaan, dan yang mengejutkan, kasus seperti itu bahkan merupakan contoh persis dalam pelatihan antipishing
  • Justru hampir kebalikannya. Sudah terdokumentasi dengan baik bahwa penipuan yang paling gamblang dan konyol justru paling efektif, karena dengan begitu penipu bisa menyaring calon korban yang paling mudah tertipu
    https://www.microsoft.com/en-us/research/publication/why-do-...
  • Sepertinya tergantung orangnya. Ada manajer yang harus menyetujui pembayaran seperti ini berkali-kali dalam sehari sehingga percakapan semacam itu bisa terasa merepotkan, dan karyawan juga mungkin ingin menghindari percakapan seperti itu
    Penyerang bisa menyisipkan kalimat seperti “Saya sedang dalam perjalanan dinas. Kalau belum yakin, telepon ponsel pribadi saya...”, lalu menjawab dengan suara palsu
    Cara yang bagus untuk menjangkau target bisa berupa “penerusan ganda”. Pengirim berperan sebagai karyawan yang meneruskan email manajer kepada karyawan di dekat staf administrasi, lalu karyawan itu meneruskan kembali email yang tampak tidak berbahaya dengan alasan seperti ucapan ulang tahun atau pemberitahuan cuti sakit, sehingga target sebenarnya sulit mengetahui asal email tersebut
    Selain itu, mudah membayangkan cara yang lebih kreatif untuk menyalahgunakan “fitur” ini. Misalnya, membuat orang yang tidak tahu apa-apa meneruskan konten bermasalah, lalu memerasnya
  • Jika email seperti ini dikirim ke departemen utang usaha di perusahaan besar, itu mungkin tidak terlalu tidak realistis
    Petugas tidak akan menelepon manajer lini setiap kali ada permintaan pembayaran lewat email, terutama jika nominalnya kecil dan tidak memerlukan persetujuan sebelumnya
    Saya ingat Google juga pernah menjadi korban penipuan yang membuat mereka membayar seseorang padahal tidak ada pekerjaan sungguhan. Kasus itu melibatkan faktur palsu, tetapi prinsipnya sama
  • Secara teoretis, ini bisa memungkinkan serangan yang lebih canggih dan tertarget, seperti mengubah penerima transfer. Serangan seperti itu jauh lebih sulit dideteksi

• Beberapa hari lalu saya melihat desain email “pembaruan” yang dibuat seorang desainer, dan karena header grafis yang sangat besar dan tidak masuk akal di bagian atas, teks judul email pun tidak terlihat tanpa menggulir
  Lalu ia meneruskan versi lain untuk meminta masukan, tiba-tiba tampak bingung karena font terlihat agak mengecil, lalu berkata, “Oh, kalau diteruskan, ini berubah menjadi versi desktop, bukan versi mobile!”
  Saya menatapnya kosong karena sulit percaya. Ini email, jadi apa maksudnya “versi desktop” dan “versi mobile”? Bagaimana hal seperti itu bisa ada? Apa maksudnya “berubah”? Bukankah itu hanya disalin? Fakta bahwa email itu “rusak” saat diteruskan saja sudah menunjukkan betapa bodohnya pendekatan ini. Kenapa harus ada CSS di email saya?
  Kalau sekadar ingin menampilkan teks miring, seharusnya sejak awal dipakai cara yang jauh lebih sederhana seperti Markdown, dan tidak masuk akal bahwa sampai sekarang belum begitu. Ini menunjukkan betapa sedikitnya minat untuk benar-benar memperbaiki situasi ini. Semuanya hanya demi memenuhi kebutuhan korporat yang aneh untuk menaruh logo dan banner di mana-mana. Email HTML benar-benar absurd

  • Jika hanya ingin menampilkan teks miring dan semacamnya, sepertinya yang Anda inginkan adalah text/enriched [1] yang muncul pada 1996. Hampir semua klien email kemungkinan mendukung pembacaannya
    [1] https://www.rfc-editor.org/rfc/rfc1896.txt
  • Framework email responsif seperti MJML memang benar-benar ada

• Sudah lama saya berpendapat bahwa teks kaya dalam email seharusnya memakai bentuk Markdown tanpa HTML inline, atau markup teks sederhana serupa, alih-alih HTML
  Dengan begitu, klien email bisa dengan mudah memutuskan apakah akan menampilkannya sebagai teks kaya atau teks biasa, sekaligus mendukung sebagian besar pemformatan yang dibutuhkan pengguna umum: tebal, miring, kutipan, gambar inline, blok kode, judul, dan sebagainya
  Ini memang tidak ideal untuk email pemasaran yang memakai HTML sangat canggih, tetapi saya tidak merasa kita perlu memedulikan kasus penggunaan seperti itu

  • Ada yang mirip, yaitu text/enriched yang didefinisikan dalam RFC 1896. Apple Mail dan lainnya juga mendukungnya
    https://en.wikipedia.org/wiki/Enriched_text
    https://www.rfc-editor.org/rfc/rfc1896.html
  • Banyak parser Markdown mengizinkan HTML inline. Di beberapa bahasa, sebagian besar begitu, dan hanya sebagian parser yang memungkinkan fitur itu dimatikan. Benar-benar bodoh
  • Cara menampilkan HTML di terminal teks seperti browser Lynx juga bekerja cukup baik, jadi saya tidak tahu kenapa kita perlu bahasa markup lain
  • Sulit mendapatkan adopsi yang cukup. Standar email memang sulit diubah
    Bahkan dukungan untuk membuat hyperlink di email saja belum ada, dan baru-baru ini ada upaya untuk memperbaikinya
    https://pastebin.com/kHQs50xm
  • Warna dan ukuran adalah elemen dasar dan berguna dalam penulisan

• Risiko nyata bagi organisasi adalah ketika pengembang yang ditugaskan membuat email HTML menjadi gila, mengurung diri di ruang server, lalu berteriak “kenapa rendering Outlook hasilnya beda” sambil menghancurkan semua perangkat keras.
  Tentu saja, kalau bicara serius, ini adalah kerentanan yang sangat menarik.

  • Karena itu, sejak beberapa tahun lalu, untuk pekerjaan terkait email saya memutuskan cukup membayar layanan coding email HTML. Mengodekan template HTML yang lolos pengujian Litmus membutuhkan banyak pengetahuan khusus, dan saya tidak ingin masuk ke sana lagi.

• Bukankah ini bisa diperbaiki dengan tidak mengizinkan stylesheet dan hanya mengizinkan atribut style inline pada tag?
  Demi kegunaan, klien email juga bisa menambahkan tahap otomatis yang “mengompilasi” semua stylesheet menjadi style inline.
  Dengan begitu, yang rusak hanya selector CSS tingkat lanjut, misalnya hover, dan saya tidak begitu yakin hal-hal seperti itu benar-benar diperlukan.

  • Setuju. Sepertinya masalahnya bisa diselesaikan dengan memanggang semua class menjadi style inline sebelum menampilkan email. Lagi pula, pendekatan itu memang masuk akal.
    Pseudo-class dan media query tidak akan berfungsi, tetapi itu bisa menjadi risiko keamanan dan juga tidak didukung di klien email utama: https://www.caniemail.com/features/css-at-media/
  • Email HTML memang sudah harus meng-inline CSS karena Outlook dan Gmail memakai mesin rendering yang sudah berumur puluhan tahun. Outlook secara harfiah memakai mesin HTML MS Word dari sekitar tahun 2006.
    Selain itu, jika semua atribut style dimatikan, optimisasi mobile dan dark mode juga ikut mati. Media query tidak bisa di-inline.
  • Kalau begitu, pendekatan email responsif yang ada sekarang juga akan rusak.
    Biasanya style dasar/desktop sudah dikompilasi dan di-inline, lalu selector media query ditempatkan dalam tag style di dalam head agar mudah dibaca di perangkat mobile.

• Benar-benar cerdas.
  Premisnya adalah, karena CSS pada email HTML, sebagian teks bisa baru terlihat setelah pesan diteruskan. Ini merupakan ancaman besar terhadap kepercayaan pada email yang sudah diverifikasi.
  Contoh Thunderbird, Outlook, dan Gmail disajikan, dan ini pekerjaan yang bagus.
  Saya membaca semua email di mutt, jadi secara resmi ini “masalah orang lain”.
  Jadi kalau mau mengeluh soal hal lain, tanggal pelaporan ke Mozilla tertulis 05.03.2024. Saya setuju bahwa tanggal little-endian lebih masuk akal daripada tanggal middle-endian gaya Amerika.
  Namun, sebagai orang teknis, saya menganggap tidak memakai format tanggal ISO 8601, yaitu 2024-03-05, dengan atau tanpa tanda hubung, adalah hal yang keliru :)

  • Bukan cuma itu, siapa pun yang memakai format tanggal middle-endian sedang melakukan kesalahan. Itu cara paling tidak rasional untuk menulis sesuatu.
    Little-endian setidaknya punya kelebihan karena berkebalikan dengan cara kita menulis semua angka lain, tetapi middle-endian benar-benar cara yang tidak waras. Tentu saja, karena itu pula cara yang dipakai orang Amerika.

• Terlihat bahwa beberapa klien email yang disebutkan membungkus isi email dengan tag HTML tambahan serta mengubah CSS dan nama class.
  Saya penasaran mengapa klien email tidak memakai iframe sandbox saat me-render email HTML. Apakah masih ada risiko keamanan?

  • HTML tambahan itu tidak muncul di klien yang membaca email yang sudah diteruskan, melainkan muncul saat meneruskan email.
    Orang yang meneruskan email mungkin ingin menambahkan lebih banyak teks ke email, jadi itu perilaku yang dapat diperkirakan.
  • Dulu pernah memakai iframe dan ada masalah. Bukan masalah rendering atau keamanan; seingat saya bagian itu bekerja dengan baik.
    Namun, jika email memiliki tautan ke situs web dan iframe sandbox tidak mengizinkan JavaScript, konteks keamanan tersebut berlanjut hingga halaman yang dibuka dengan mengeklik tautan di dalam iframe, sehingga situs web tidak bisa memakai JS.
    Solusinya adalah allow-popups-to-escape-sandbox, jadi sekarang tampaknya tidak ada alasan mengapa itu tidak bisa berfungsi.

• Ini solusi klasik memotong anggota tubuh untuk menyembuhkan luka. Masalahnya adalah standardisasi email yang buruk yang membiarkan peretasan seperti ini mendominasi.
  HTML secara umum memang rentan terhadap kekhawatiran semacam ini. Meski begitu, ada banyak email yang memakai HTML tanpa masalah. Tulisan ini terbaca seperti frustrasi pribadi terhadap sesuatu yang ditemui di alam liar, lalu dikemas sebagai masalah keamanan.

• Mitigasi yang mungkin terpikir oleh saya seperti ini, meski bisa saja tidak efektif: memberi peringatan yang mencolok pada elemen tersembunyi, mengacak jumlah div pembungkus di sisi penerima dan pengirim, menghitung bagaimana tampilan sebenarnya saat diteruskan lalu meminta konfirmasi jika perbedaannya besar.
  Atau, menangani kebalikannya mungkin lebih efektif, karena tidak membutuhkan bantuan dari klien lain.

• Cukup ubah menjadi “mengapa email berbahaya bagi organisasi”.

  • Pada titik itu, jadinya hanya “mengapa komunikasi dengan pihak luar berbahaya bagi organisasi”.
    Tulisan ini menyajikan jalur serangan yang unik untuk email HTML, tetapi sebagian besar serangan melalui email dapat dengan mudah dipindahkan ke WhatsApp, Slack, Jira, Zoom, atau alat apa pun yang dipakai orang untuk berkomunikasi dengan pihak luar.