Surat Kobold: Bahaya Email HTML

 (lutrasecurity.com)
2 poin oleh GN⁺ 2024-04-05 | 1 komentar | Bagikan ke WhatsApp

Surat Kobold

  • Orang-orang yang harus menangani email HTML secara teknis kemungkinan pernah sampai pada titik ingin berhenti dari pekerjaannya atau ingin membakar semua klien email karena implementasi yang tidak konsisten antar-klien.
  • Email HTML bukan sekadar sumber kejengkelan, tetapi juga bisa menjadi risiko keamanan yang serius.
  • Bayangkan atasan Anda meneruskan email yang memerintahkan transfer sejumlah besar uang; karena Anda pernah mendengar tentang penipuan CEO, Anda memeriksa apakah email itu benar-benar berasal dari atasan Anda.
  • Email itu memang berasal dari atasan Anda, dan jika perusahaan Anda melakukan itu, mungkin bahkan ditandatangani secara kriptografis.
  • Namun Anda masih belum yakin, jadi Anda menelepon atasan Anda untuk memverifikasi keaslian email tersebut.
  • Setelah atasan Anda mengonfirmasinya, Anda mentransfer uangnya.
  • Namun jika ini bukan penipuan, artikel ini seharusnya berakhir di sini.

Thunderbird

  • Masalah ini dilaporkan ke Mozilla pada 5 Maret 2024, dan tanggal rilis yang direncanakan serta draf bagian berikutnya disampaikan ke Mozilla pada 20 Maret 2024.
  • Kemungkinan langkah mitigasi telah dibahas, tetapi baru akan diimplementasikan nanti.
  • Mengeksploitasi ini di Thunderbird itu mudah. Thunderbird membungkus email dengan `

` dan selain itu tidak mengubah apa pun.

  • Saat email diteruskan, email yang dikutip dibungkus dengan `

` lain sehingga turun satu tingkat di DOM.

  • Dengan mempertimbangkan hal itu, berikut proof of concept-nya:

      .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.
  • Email tersebut berisi teks yang selalu terlihat dan teks tersembunyi dengan display: none;.
  • Saat email diteruskan, teks tersembunyi itu tiba-tiba menjadi terlihat hanya bagi penerima baru.

Outlook Web

  • Masalah ini dilaporkan ke Microsoft pada 5 Maret 2024, dan tanggal rilis yang direncanakan serta draf bagian berikutnya disampaikan ke Microsoft pada 20 Maret 2024.
  • Pada 26 Maret 2024, Microsoft memutuskan untuk tidak mengambil tindakan segera dan menutup laporan tersebut.
  • Di Outlook Web (OWA), situasinya sedikit lebih rumit. Email dibungkus dengan `

`, tetapi nama kelas yang tepat bisa berubah.

  • Agar CSS email tidak memengaruhi gaya milik webmailer, Outlook menambahkan prefiks x_ pada semua id dan kelas dalam email serta menyesuaikan CSS-nya.
  • Dengan mempertimbangkan hal itu, berikut proof of concept-nya:

      .kobold-letter {
        display: none;
      }
      body>div>.kobold-letter {
        display: block !important;
      }

    This text is always visible.

    This text will only appear after forwarding.
  • Saat email ditampilkan di OWA, CSS-nya terlihat seperti berikut:
  • Setelah email diteruskan, surat kobold dibungkus lagi dengan `` lain dan CSS diperbarui sekali lagi.

Gmail

  • Masalah ini dilaporkan ke Google pada 5 Maret 2024, dan tanggal rilis yang direncanakan serta draf bagian berikutnya disampaikan ke Google pada 20 Maret 2024.
  • Secara teknis Gmail tidak rentan terhadap surat kobold, karena semua gaya dihapus saat email diteruskan.
  • Saat email diteruskan, surat kobold yang disembunyikan dengan CSS akan otomatis muncul sampai CSS tersebut dihapus.

Penelitian Sebelumnya

  • Kemungkinan seperti ini bukanlah hal yang mengejutkan atau baru.
  • Masalah serupa pernah dilaporkan di masa lalu.

Prospek

  • Pengguna dapat mengurangi risiko surat kobold dengan menonaktifkan email HTML sepenuhnya atau melihatnya dalam mode terbatas.
  • Untuk klien email, mitigasi ini sulit diimplementasikan. Mencegah penggunaan `` bisa menyelesaikan masalah, tetapi juga dapat merusak banyak solusi yang sudah ada di ekosistem email.
  • Sayangnya, tidak realistis mengharapkan klien email akan menerapkan mitigasi yang kokoh dalam waktu dekat.

Opini GN⁺

  • Artikel ini menunjukkan kerentanan email HTML, khususnya serangan 'surat kobold' di mana isi email dapat berubah ketika email diteruskan. Ini merupakan informasi penting yang meningkatkan kewaspadaan pengguna email terhadap keamanan.
  • Artikel ini menunjukkan bahwa kerentanan keamanan dapat muncul bergantung pada cara klien email menangani CSS, dan mendorong pengguna maupun pengembang untuk lebih memperhatikan keamanan.
  • Serangan seperti ini sangat berbahaya karena tampak seolah-olah berasal dari sumber yang dipercaya pengguna. Hal ini menegaskan perlunya selalu waspada dalam komunikasi melalui email.
  • Dari sudut pandang teknis, pengembang klien email perlu memperbaiki cara penanganan CSS untuk mencegah serangan seperti ini. Namun, hal tersebut dapat menimbulkan masalah kompatibilitas dengan desain email yang sudah ada, sehingga penting untuk menemukan keseimbangan yang tepat.
  • Artikel ini bukan tentang teknologi baru atau open source, tetapi menyajikan hal-hal yang perlu dipertimbangkan saat mengadopsi teknologi terkait keamanan email. Pengembang klien email perlu mencari cara untuk memperkuat keamanan pengguna sambil tetap menjaga kegunaan.

Bacaan terkait

1 komentar

 
GN⁺ 2024-04-05
Opini Hacker News

  • “However, you are still not convinced, so you call your manager to ensure that the email is legit. He confirms, so you transfer the money.”

    • Komentar ini menekankan bahwa ketika muncul kecurigaan atas permintaan transfer uang melalui email, jangan hanya bertanya "apakah Anda mengirim email ini", melainkan harus bertanya secara spesifik seperti "apakah Anda benar-benar ingin uang ini ditransfer seperti ini". Menurutnya, percakapan seperti ini akan membuat serangan jauh lebih mungkin gagal. Komentar ini juga menunjukkan bahwa agar skenario serangan yang dijelaskan dalam artikel berhasil, dibutuhkan situasi yang sangat spesifik dan sempit, sehingga dipertanyakan seberapa besar kemungkinan serangan serumit itu benar-benar berhasil.

  • The other day I was discussing the design for an "update" email that our designer was putting together...

    • Komentar ini membagikan pengalaman tentang desain email. Ia menyoroti masalah header grafis pada email buatan desainer yang membuat penerima harus menggulir ke bawah untuk melihat subjek, dan menyatakan keheranannya bahwa saat email diteruskan, versi seluler berubah menjadi versi desktop. Ia mengkritik penggunaan CSS dalam email sebagai sesuatu yang tidak perlu, serta mengeluhkan bahwa hingga kini belum ada adopsi markup teks sederhana seperti Markdown.

  • I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...

    • Komentar ini berpendapat bahwa email seharusnya menggunakan Markdown (tanpa inline HTML) atau markup teks sederhana serupa, bukan HTML. Dengan begitu, klien email akan lebih mudah menentukan apakah pesan perlu ditampilkan sebagai rich text atau teks biasa, sambil tetap mendukung sebagian besar format yang dibutuhkan pengguna. Ia juga berpendapat bahwa HTML canggih yang dipakai pada email pemasaran sebenarnya tidak penting.

  • The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...

    • Komentar ini bercanda bahwa risiko sebenarnya bagi organisasi adalah developer yang ditugaskan membuat email HTML bisa menjadi gila karena perbedaan rendering di Outlook, sambil menambahkan bahwa serangan melalui email seperti ini memang menarik.

  • Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?

    • Komentar ini mengusulkan apakah masalah tersebut bisa diatasi dengan tidak mengizinkan stylesheet dan hanya memperbolehkan atribut style inline pada tag. Menurutnya, kegunaan dapat ditingkatkan bila klien email menambahkan langkah yang secara otomatis mengubah stylesheet menjadi style inline.

  • HTML in email shouldn't be as big of a nightmare as it is.

    • Komentar ini mengatakan bahwa HTML dalam email seharusnya tidak menjadi mimpi buruk sebesar ini. Menurutnya, masalahnya bisa mudah diselesaikan jika semua klien email memeriksa apakah pesan berupa teks atau HTML, lalu beralih ke mesin rendering WebKit jika itu HTML. Ia juga bertanya-tanya apakah pernah ada standar yang diusulkan untuk hal ini.

  • Some possible mitigations from the top of my head (maybe ineffective):

    • Komentar ini mengajukan beberapa cara yang mungkin dapat mengurangi serangan melalui email. Contohnya termasuk memberi peringatan untuk elemen tersembunyi, serta saat meneruskan email menghitung seperti apa tampilan pesan dan meminta konfirmasi jika hasilnya berubah terlalu besar.

  • When efail came out, I wrote a blogpost about the security risks of HTML mail.

    • Komentar ini menyebut bahwa ia pernah menulis posting blog tentang risiko keamanan email HTML. Ia menunjukkan bahwa spesifikasi email HTML sudah tua dan hampir tidak memiliki pertimbangan keamanan; email HTML yang aman seharusnya merupakan subset dari HTML, tetapi tampaknya tidak ada yang mendefinisikan subset itu, sehingga celah keamanan terus bermunculan.

  • This is really clever!

    • Komentar ini memuji betapa cerdiknya penggunaan CSS dalam email HTML untuk membuat teks tertentu hanya terlihat setelah pesan diteruskan. Menurutnya, hal ini bisa menjadi ancaman besar terhadap keandalan email yang sudah diverifikasi. Ia juga menyatakan rasa ingin tahu tentang praktik klien email yang membungkus isi email dengan tag HTML tambahan serta memodifikasi CSS dan nama kelas. Selain itu, ia mempertanyakan mengapa klien email tidak menggunakan iframe yang disandbox untuk merender email HTML.