Kerentanan clickjacking WhatsApp memungkinkan serangan phishing

• Ditemukan kerentanan phishing di WhatsApp yang menampilkan tautan dan pratinjau seolah-olah menuju situs normal, padahal klik sebenarnya diarahkan ke situs penyerang
• Penyebabnya adalah tautan di isi pesan dan data pratinjau dikirim secara terpisah, serta dengan menghapus matchedText dapat dibuat ketidaksesuaian pratinjau
• Karakter U+202E Right-To-Left Override dapat membalik arah tampilan URL sehingga domain sebenarnya terlihat seperti domain normal
• Penyerang dapat menyiapkan domain mirror dari target penyamaran, lalu mempertahankan pratinjau situs asli dan hanya mengubah nilai text untuk menipu korban
• Meta mengatakan logika normalisasi URL dapat disesuaikan secara dinamis, dan pengguna sebaiknya menyalin tautan terlebih dahulu untuk memeriksa alamat sebenarnya sebelum mengeklik

---

Titik pemisahan antara pratinjau tautan dan tautan sebenarnya di WhatsApp

• Peneliti mengirim tautan webhook.site kepada temannya untuk memeriksa apakah saat penerima WhatsApp merender pratinjau tautan, permintaan HTTP juga terjadi
• Permintaan HTTP hanya terjadi satu kali di sisi pengirim, sehingga dipastikan bahwa penerima tidak merender tautan secara terpisah
• Karena perilaku ini, peneliti menilai bahwa tautan dan informasi pratinjau dikirim bersama di dalam pesan WhatsApp, lalu menguji apakah keduanya bisa dibuat berbeda

Issue #1: Ketidaksesuaian pratinjau tautan

• Peneliti sempat mencoba memodifikasi langsung pesan WhatsApp Web melalui proksi, tetapi karena E2EE WhatsApp, manipulasi sederhana dengan alat seperti Burp Suite tidak mudah dilakukan
• Sebagai gantinya, ia memasang breakpoint pada JavaScript tepat sebelum pesan dienkripsi dan dikirim melalui WebSocket untuk memeriksa objek pesan
• Di dalam objek pesan, isi tautan dan informasi pratinjau ada sebagai properti terpisah
  • text: isi pesan
  • canonicalURL: domain yang ditampilkan di bagian bawah pratinjau
  • matchedText: tampaknya nilai yang dibandingkan dengan canonicalURL, dan diuji apakah nilai tersebut juga muncul di dalam text
• Jika pada objek pesan untuk instagram.com nilai text diubah menjadi google.com, pratinjau akan hilang dan hanya tautan Google yang tersisa
• Jika properti matchedText dihapus, dapat dibuat pesan tidak cocok antara tautan sebenarnya dan pratinjau

Issue #2: Kamuflase tampilan tautan dengan U+202E

• Agar isi tautan sebenarnya tidak terlihat jelas, peneliti melakukan fuzzing untuk melihat apakah karakter Unicode dapat mengubah tampilan teks
• U+202E adalah karakter Right-To-Left Override yang membuat teks ditampilkan terbalik kepada pengguna
• Jika hanya menggunakan U+202E, bentuk tautannya terlihat janggal dan kemungkinan diklik menjadi rendah, sehingga perlu menyusun string terbalik yang tampak seperti URL normal

Cara menyusun URL mirror

• Tujuannya adalah membuat URL yang saat dibalik akan terlihat seperti https://instagram.com
• String yang dibalik secara sederhana menjadi moc.margatsni//:sttph, tetapi TLD seperti .margatsni tidak bisa didaftarkan
• Solusinya adalah menggunakan TLD yang benar-benar dapat didaftarkan agar terlihat seperti subdomain
  • Sebagai contoh, dengan memakai TLD Belanda .nl, dapat dibuat string yang terlihat seperti ln.instagram.com
• Karena URL harus tampak diawali https://, peneliti menambahkan //:sptth di belakang sebagai path yang valid
• Hasilnya, https://moc.margatsni.nl//:sptth bila digabungkan dengan U+202E dapat terlihat seperti https://ln.instagram.com//:sptth
• Peneliti menamai metode ini 2K2E

Alur serangan

• Penyerang membeli domain mirror dari situs yang ingin ditiru
  • Contoh: agar terlihat seperti ln.instagram.com, penyerang membeli moc.margatsni.nl
• Mula-mula dibuat pesan yang berisi tautan domain asli untuk memperoleh pratinjau situs tersebut
  • Pada contoh objek, text, matchedText, dan canonicalUrl semuanya berisi https://instagram.com/
  • Nilai terkait pratinjau seperti description, title, jpegThumbnail, thumbnailDirectPath juga ikut ada
• Setelah itu matchedText dihapus dan nilai text diubah menjadi bentuk \u202ehttps://moc.margatsni.nl//:sptth
• Pesan akhirnya menampilkan pratinjau Instagram, tetapi saat diklik dapat membawa korban ke domain yang disiapkan penyerang

Respons Meta dan perbandingan dengan platform lain

• Meta menjawab bahwa karena harus mendukung banyak platform dan lingkungan, cara normalisasi URL per platform bisa berbeda dari logika sisi server
• Meta juga menyebut memiliki sistem yang dapat menyesuaikan logika normalisasi URL secara dinamis bila benar-benar terjadi spam dan penyalahgunaan
• Peneliti menilai Meta tampak tidak berupaya aktif menyelesaikan isu keamanan ini, dan hanya akan merespons ketika sistem mendeteksinya sebagai spam
• X, TikTok, dan Pinterest melakukan sanitasi terhadap karakter U+202E, sehingga berbeda dari WhatsApp

Mitigasi yang bisa dilakukan pengguna

• Tautan WhatsApp sulit dipercaya hanya berdasarkan tampilan yang terlihat
• Untuk menghindari phishing 2K2E, pengguna perlu menyalin tautan sebelum mengekliknya lalu memeriksa alamat sebenarnya di pratinjau clipboard
• Pratinjau clipboard dapat menampilkan alamat tautan dalam keadaan karakter U+202E sudah disanitasi
• Peneliti kemudian juga menemukan layanan lain yang rentan terhadap 2K2E karena tidak memiliki sanitasi yang memadai

[GN⁺]

Komentar di Hacker News

• Ini kombinasi penyalahgunaan fitur yang cukup cerdik, tetapi menurut saya dampak keamanannya secara keseluruhan rendah
  Dalam skenario terbaik sekalipun, ini hanya membuat penerima membuka tautan di browser, jadi kecuali penyerangnya polisi atau badan intelijen, biasanya masih perlu serangan lanjutan seperti mengeksploitasi perangkat lunak yang belum ditambal di perangkat
  Secara teknis, ini kurang tepat disebut clickjacking. Clickjacking biasanya merujuk pada teknik yang sangat spesifik: menumpuk frame HTML tak terlihat di atas konten lain
  https://owasp.org/www-community/attacks/Clickjacking
  https://portswigger.net/web-security/clickjacking

  • Saya juga tidak akan menyebut ini clickjacking. Clickjacking yang sebenarnya adalah teknik yang membuat korban melakukan aksi terkait akun tanpa sadar, dan sekadar membuka tautan yang tidak dimaksudkan tidak separah itu
  • Jika tautan itu menampilkan layar login yang persis sama dengan Instagram, berapa persen pengguna yang setelah sempat terkecoh oleh pratinjau WhatsApp akan memeriksa URL-nya lagi?

• Semua orang hanya fokus pada karakter kanan-ke-kiri UTF, tetapi Meta setidaknya seharusnya mengakui masalah bahwa URL pratinjau bisa berbeda dari URL pesan
  Saya paham ini perilaku untuk memperluas URL pendek, tetapi pasti ada solusi cerdas yang bisa diterapkan Meta dan WhatsApp

  • Tidak. Dalam enkripsi end-to-end, pratinjau harus dibuat di sisi pengirim atau penerima. Jika penerima yang membuat pratinjau, IP-nya bocor. Pada akhirnya fitur pratinjau harus dihapus

• Clickjacking adalah ketika Anda mengira mengklik suatu elemen, tetapi sebenarnya elemen lain—biasanya transparan dan ditumpuk di atasnya—mencegat event klik
  Dengan memberi fokus pada layer bawah yang terlihat lalu mendeteksi event onblur, penyerang bisa mengetahui klik meski pengguna tidak menerima event tersebut
  Temuan OP memang keren, tetapi ini bukan clickjacking. Dulu saya juga pernah menggunakan karakter RTL untuk membuat file screensaver, yaitu executable biasa di Windows yang hanya berbeda ekstensi, tampak seperti dokumen Word. Sepertinya untuk mengerjai teman atau guru, tetapi saya tidak ingat persis alasannya
  OP melangkah lebih jauh dengan menemukan cara agar tampilannya berubah di sistem lain. Ini bukan membuat pengguna keliru tentang elemen apa yang diklik, melainkan keliru tentang ke mana tautan akan menuju, jadi bukan clickjacking; halaman Wikipedia yang ditautkan di awal tulisan juga mengonfirmasi demikian
  Saya belum pernah benar-benar melihat clickjacking dieksploitasi, tetapi metode yang ditemukan OP ini terasa bisa disalahgunakan
  Sejujurnya, saya sudah lama menyerah pada harapan bahwa pengguna bisa membedakan domain akhir saat mengklik tautan. Mayoritas tidak memahami konsepnya sama sekali, dan sisanya pun sulit membedakannya
  Bahkan orang yang merasa bisa membedakannya akan frustrasi jika semua tautan mengarah ke tempat seperti sendgrid.tld/j3ovi3bfogobbledypoop93jnri2o. Setiap hari kita melatih orang untuk mengklik tautan mencurigakan yang diobfuskasi untuk pelacakan, dan tidak ada yang peduli

• Peretasan yang keren. Masalah sebenarnya bukan WhatsApp atau karakter Unicode arah terbalik, melainkan URL itu sulit
  Contoh sederhana seperti visa.securesite.com saja sudah menipu banyak orang. Saya tidak melihat solusi bagus dalam waktu dekat

  • Dalam kasus spesifik ini, ketika pengguna mencoba memahami target klik, sistem secara aktif menyesatkan mereka, jadi ini lebih mirip sanitasi yang buruk
    Kebingungan umum seputar hostname dan domain adalah masalah yang lebih sulit, tetapi browser telah mencoba menguranginya sampai batas tertentu dengan menyorot bagian nama domain. Seperti kebanyakan teknik phishing, pada akhirnya passkey sepertinya akan mengakhirinya

• RTL telah menjadi sumber kerentanan keamanan besar selama keberadaannya. Saya tidak mengerti mengapa sistem operasi tidak punya pengaturan untuk menonaktifkan semua RTL, supaya orang yang tidak mengenal bahasa-bahasa itu tidak terpapar risiko tanpa manfaat apa pun

  • Terlepas dari sistem operasi, setiap widget OS yang menampilkan teks seharusnya punya opsi seperti itu. Termasuk Android TextView
    Secara default, semua bypass teks dua arah harus dinonaktifkan kecuali developer secara eksplisit meninjau dan mengizinkan rentang teks tertentu
    Tidak masuk akal membuat seluruh stack rendering teks rentan secara default atas nama mengakomodasi kurang dari 1% populasi dunia

• Mengecewakan bahwa Meta tidak memperbaiki masalah ini dan juga memutuskan tidak membayar bug bounty kepada peneliti ini

  • Awal tahun ini saya melaporkan masalah serupa ke Google, tetapi ditolak dengan alasan “hanya bisa terjadi melalui rekayasa sosial” dan “kami menilai perbaikannya tidak akan membuat pengguna secara berarti menjadi kurang rentan”
    Saya tidak akan menjelaskan detailnya di sini, tetapi karena cara Google Search kadang menulis ulang URL, penyerang bisa memalsukan URL sebenarnya
    Sebaiknya jangan pernah memercayai URL yang ditampilkan di situs web dan aplikasi
  • Mungkin mereka terlalu sibuk mengirim ancaman hukum ke proyek OSS
  • Mungkin permintaan perbaikannya tidak cukup jelas, misalnya apakah yang diminta adalah memblokir karakter RTL, dan Meta menafsirkannya sebagai permintaan memperbaiki semua URL yang menyesatkan. Itu pada dasarnya mustahil
  • Mereka akan memperbaikinya. Hanya saja tidak akan memberi imbalan kepada bounty hunter

• Bagian “tepat seperti yang diduga, tautan dan pratinjau dikirim terpisah!” adalah masalah desain UI yang lebih besar. Mengapa pengguna biasa harus membandingkan tautan dan pratinjau demi keamanan?

  • Ini kompromi keamanan. Untuk menyediakan fitur berguna seperti pratinjau tautan, ada beberapa opsi
    1. Dibuat di sisi pengirim. Kekurangannya, bisa dipalsukan
    2. Dibuat di sisi penerima. Kekurangannya, IP penerima bocor
    3. Dibuat melalui pihak ketiga. Kekurangannya, informasi bocor ke pihak ketiga
       Secara keseluruhan, menurut saya nomor 1 adalah yang terbaik. Pengirim toh bisa “memalsukan” semua pesannya sendiri, dan memasukkan pratinjau sebagai bagian dari pesan tidak jauh berbeda
       Masalahnya di sini adalah tidak jelas bahwa konten ini berasal dari pengirim. Karena ditampilkan seperti gelembung pesan terpisah, 99% pengguna kemungkinan tidak akan tahu bahwa konten itu disediakan oleh pengirim
       Lagi pula URL adalah inti masalahnya. Jika pengguna mengklik URL yang dikendalikan penyerang, penyerang bisa menampilkan apa pun yang diinginkan di pratinjau. Jadi manfaat memaksa pratinjau menjadi “asli” sangat kecil
       Opsi 3 juga bisa cukup baik. Terutama jika diimplementasikan dengan semacam double-blind: menghubungi satu pihak, lalu pihak itu meneruskan ke pihak kedua. Dengan begitu pihak pertama melihat IP dan pihak kedua melihat tujuan, tetapi selama tidak berkolusi, tidak ada yang melihat keduanya sekaligus
       Namun manfaatnya relatif kecil untuk membangun dan memelihara infrastruktur sebesar itu

• Saya suka bahwa di bagian paling bawah tulisan ini diklasifikasikan sebagai reverse engineering

• Ini bukan clickjacking. Clickjacking adalah ketika penyerang mencegat klik sehingga pengguna benar-benar mengklik target lain yang tidak mereka maksudkan atau sadari
  Codepoint RTL yang membuat teks mengalir dari kanan ke kiri adalah fitur internasionalisasi, dan menggunakannya untuk membingungkan orang bukanlah kerentanan baru