Perangkat penyadap WebRTC: musuh baru pembayaran online

Perangkat lunak penyadap WebRTC telah menjadi salah satu masalah paling serius bagi toko online modern. Kita tidak lagi berbicara tentang JavaScript biasa yang mengirimkan data kartu kredit melalui HTTP ke domain yang mencurigakan, tetapi lebih kepada kode yang mampu menggunakan saluran data WebRTC terenkripsi untuk mengekstrak informasi tanpa memicu kontrol keamanan standar. Jika Anda mengelola situs e-commerce dan masih berpikir bahwa WAF yang baik dan CSP yang ketat adalah semua yang Anda butuhkan, skenario ini sangat menarik bagi Anda.

Dalam insiden baru-baru ini yang dianalisis oleh perusahaan spesialis seperti Sansec, sebuah perangkat lunak penyadap WebRTC telah diamati mengeksploitasi kerentanan kritis seperti PolyShell di Magento dan Adobe Commerce untuk menyusup ke server, menyuntikkan skrip ke dalam proses pembayaran, dan membangun saluran WebRTC langsung ke infrastruktur penyerang. Hasilnya adalah kombinasi yang berbahaya: akses mudah, persistensi tanpa suara, dan eksfiltrasi data pembayaran yang tidak transparan, dengan memanfaatkan kelemahan desain dalam standar yang banyak digunakan seperti Content Security Policy (CSP).

Apa itu skimmer dengan WebRTC dan mengapa berbeda?

Ketika kita berbicara tentang skimmer dalam e-commerce, kita merujuk pada skrip berbahaya yang mencuri data dari formulir pembayaran (nomor kartu, tanggal kedaluwarsa, CVV, alamat, dll.) saat pelanggan menyelesaikan pembelian. Yang baru dari skimmer WebRTC adalah saluran komunikasi yang digunakannya: alih-alih mengandalkan permintaan HTTP POST, gambar phishing, atau WebSocket, ia menggunakan WebRTC DataChannels melalui UDP yang dienkripsi dengan DTLS.

WebRTC diciptakan untuk memungkinkan komunikasi waktu nyata antar peramban : panggilan video, obrolan suara, berbagi layar, dan transfer file. Standar ini mencakup mekanisme seperti RTCPeerConnection dan saluran data yang memungkinkan koneksi titik-ke-titik. Skimmer yang ditemukan memanfaatkan kemampuan ini untuk membuat terowongan tersembunyi yang mengekstrak data kartu kredit dari situs tersebut, melewati kontrol yang dirancang hampir secara eksklusif untuk lalu lintas HTTP atau WebSocket.

Temuan yang paling mencolok adalah bahwa Sansec mendokumentasikan untuk pertama kalinya penggunaan WebRTC DataChannels sebagai saluran eksfiltrasi spesifik untuk skimming di toko online. Hingga saat ini, kelompok seperti Magecart biasanya memilih permintaan web klasik atau, dalam skenario yang lebih canggih, WebSocket. Pergeseran ke arah WebRTC ini merupakan lompatan signifikan ke depan dalam kecanggihan kampanye-kampanye ini.

Dampaknya tidak terbatas pada toko-toko kecil. Korban yang telah dikonfirmasi termasuk produsen mobil yang bernilai lebih dari 100.000 miliar dolar AS , jaringan supermarket besar yang masuk dalam peringkat 10 besar global, dan perusahaan-perusahaan bernilai miliaran dolar lainnya. Para penyelidik telah mendeteksi alat skimmer jenis ini di setidaknya lima organisasi besar hanya dalam dua bulan, menunjukkan bahwa ini bukan insiden terisolasi , melainkan tren yang jelas menuju teknik yang lebih tersembunyi.

Cara menggunakan WebRTC skimmer langkah demi langkah

Inti dari serangan ini adalah skrip JavaScript yang dapat dieksekusi sendiri yang disuntikkan ke halaman pembayaran yang telah disusupi. Setelah dimuat ke browser korban, skrip ini menyiapkan infrastruktur WebRTC yang diperlukan untuk berkomunikasi dengan server perintah dan kontrol (C2) penyerang dan menerima kode berbahaya lebih lanjut.

Pertama, skimmer membuat RTCPeerConnection dan DataChannel . Data channel diberi tag dengan URL halaman saat ini, memungkinkan penyerang untuk mengetahui persis di mana pengguna berada di situs saat komunikasi terjadi. Informasi kontekstual ini kemudian dapat digunakan untuk menyesuaikan payload dengan alur pembelian.

Selanjutnya, malware tersebut membangun dan memanipulasi negosiasi Session Description Protocol (SDP) secara lokal. Ia menghasilkan fragmen pengguna ICE acak (ice-ufrag) dan secara statis menetapkan kata sandi ICE tertentu ( 05l0TstonL9bYAdB04I6x2 ) dalam penawaran yang dihasilkan. Kemudian, ia memodifikasi deskripsi jarak jauh untuk mensimulasikan respons yang valid yang mengarah ke server C2 dengan alamat IP 202.181.177.177 , menggunakan port UDP 3479 dan sidik jari DTLS yang telah ditentukan sebelumnya.

Yang menarik adalah seluruh pertukaran SDP ini terjadi tanpa memerlukan server pensinyalan , yang merupakan praktik standar dalam WebRTC yang sah. Penyerang telah memprogram kedua ujung negosiasi sebelumnya, memungkinkan browser korban untuk membuat sesi langsung dengan alamat IP C2, melewati infrastruktur pensinyalan yang, dalam lingkungan yang terlindungi, mungkin dipantau atau difilter.

Setelah saluran terjalin, server penyerang mengirimkan tahap kedua serangan —muatan lengkap—dalam fragmen-fragmen kecil. Metode onmessage pada DataChannel menangani pengumpulan fragmen yang diterima , baik yang berupa string teks maupun format biner, menggunakan TextDecoder bila perlu untuk merekonstruksinya dengan benar.

Ketika saluran ditutup, atau setelah sekitar 10 detik, fungsi internal yang bertanggung jawab untuk mengeksekusi muatan akan aktif . Di sinilah desain menjadi sangat rumit: kode tersebut mencoba mengeksekusi dengan berbagai cara, selalu memprioritaskan opsi yang memungkinkannya untuk melewati Kebijakan Keamanan Konten yang dikonfigurasi di situs web.

Bagaimana skimmer melewati Kebijakan Keamanan Konten dan menggunakan nonce

Salah satu aspek paling berbahaya dari serangan ini adalah bagaimana skimmer mengeksploitasi kebijakan CSP dan penggunaan nonce . Banyak pengembang mengandalkan CSP untuk membatasi skrip mana yang dapat dijalankan, dan di lingkungan yang lebih canggih, mereka menambahkan nonce acak ke skrip yang sah sehingga hanya blok kode yang diizinkan yang dimuat ke dalam browser.

JavaScript berbahaya memindai DOM untuk tag `<script>` yang sudah memiliki atribut nonce . Jika menemukannya, ia membuat elemen `<script>` baru dan menyalin nonce yang persis sama. Kemudian ia memasukkan muatan yang telah direkonstruksi ke dalam skrip dan menempatkannya di dalam dokumen, misalnya, di bagian `<head>`. Dengan berbagi nonce dengan skrip yang sah, browser menganggap bahwa blok ini juga diizinkan oleh CSP.

Jika tidak dapat menemukan nonce yang valid, skimmer mencoba pendekatan lain: ia mencoba mengeksekusi kode menggunakan `Function(payload)()` , dengan mengandalkan kebijakan untuk mengaktifkan `unsafe-eval` atau konfigurasi serupa. Jika ini juga tidak berhasil, ia menggunakan opsi ketiga: menyuntikkan tag skrip tradisional dengan isi payload dan menambahkannya sementara ke DOM untuk memaksa eksekusinya.

Terakhir, kode tersebut menggunakan requestIdleCallback jika tersedia, atau sebagai alternatif dengan setTimeout, sehingga muatan berbahaya dieksekusi selama periode ketidakaktifan browser. Hal ini mengurangi dampak kinerja dan mempersulit alat analisis berbasis AI untuk mendeteksi perilaku yang tidak biasa.

Kelemahan utama yang dieksploitasi oleh skimmer adalah bahwa WebRTC, tidak seperti HTTP, tidak tercakup oleh arahan CSP standar . Meskipun `connect-src` mengontrol pengambilan data, XHR, dan WebSocket, API RTCPeerConnection berada di luar cakupan aturan ini. Chrome telah menyertakan arahan eksperimental khusus untuk WebRTC, tetapi penggunaannya terbatas dan masih belum menjadi bagian dari perangkat yang digunakan sebagian besar situs dalam produksi.

Mengapa WebRTC mampu menembus celah pertahanan?

Sebagian besar toko online dengan tingkat kematangan keamanan tertentu sudah memiliki WAF, IDS/IPS, dan bahkan inspeksi HTTP dan WebSocket yang mendalam. Sistem-sistem ini berfokus pada melihat permintaan apa yang keluar dari server atau proxy, domain apa yang dijangkau, parameter apa yang dikirim, dan apakah ada pola eksfiltrasi yang dapat dikenali.

Dalam kasus skimmer WebRTC, semua peralatan tersebut menjadi hampir tidak berguna karena DataChannels beroperasi melalui UDP yang dienkripsi dengan DTLS . Tidak ada permintaan HTTP yang terlihat, tidak ada header yang mencurigakan, dan tidak ada URL aneh yang dapat memicu peringatan WAF. Yang diamati pada dasarnya adalah lalu lintas UDP terenkripsi ke alamat IP eksternal, sesuatu yang banyak organisasi tidak pantau dengan tingkat detail yang sama seperti lalu lintas web standar.

Selain itu, aturan CSP itu sendiri, yang secara teoritis dimaksudkan untuk bertindak sebagai jaring pengaman terhadap skrip eksternal dan koneksi tidak sah, saat ini tidak mendukung RTCPeerConnection . Oleh karena itu, situs dengan kebijakan HTTP yang sangat ketat masih dapat mengizinkan JavaScript untuk membuat saluran WebRTC langsung ke server penyerang dan mengirimkan data kartu kredit curian dari sana.

Cacat desain ini menciptakan apa yang oleh banyak administrator dianggap sebagai rasa aman palsu : mereka percaya bahwa, berkat CSP dan daftar putih domain, tidak ada hal yang tidak biasa akan keluar dari browser dan dikirim ke situs yang tidak sah. Namun, sampai arahan khusus untuk WebRTC diimplementasikan dan distandarisasi secara luas, kepercayaan ini tidak beralasan dalam menghadapi ancaman yang tahu cara mengeksploitasi RTCPeerConnection.

Yang lebih memperumit masalah, lalu lintas WebRTC sering bercampur dengan aplikasi panggilan video, obrolan, atau kolaborasi yang sah di jaringan , sehingga sulit untuk membedakan antara penggunaan yang tidak berbahaya dan yang jahat hanya berdasarkan pola jaringan. Tanpa analisis yang lebih mendalam tentang perilaku JavaScript sisi klien, skimmer memiliki banyak ruang untuk beroperasi dengan bebas.

PolyShell di Magento dan Adobe Commerce: titik masuknya

Semua kecerdikan dalam eksfiltrasi akan menjadi tidak relevan jika penyerang tidak memiliki cara efektif untuk menempatkan skrip berbahaya di toko . Di sinilah kerentanan yang dikenal sebagai PolyShell berperan, yang memengaruhi Magento Open Source dan Adobe Commerce dan telah menjadi titik masuk utama untuk jenis serangan ini.

PolyShell memungkinkan penyerang jarak jauh yang tidak terautentikasi untuk mengunggah file yang berpotensi dapat dieksekusi ke jalur server yang sensitif, biasanya melalui REST API atau direktori yang kurang aman, seperti jalur tertentu di dalam pub/media/custom_options. Setelah mendapatkan unggahan ini, mereka dapat menyebarkan web shell, backdoor, dan skrip skimming yang diperlukan untuk membahayakan alur checkout.

Para peneliti memperkirakan awal eksploitasi massal PolyShell sekitar tanggal 19 Maret 2026, tanggal di mana terjadi lonjakan tajam dalam pemindaian otomatis dari lebih dari 50 alamat IP yang berbeda. Pemindaian ini mencari instance Magento dan Adobe Commerce yang rentan untuk melancarkan intrusi skala industri.

Data yang dikumpulkan menunjukkan bahwa sekitar 56,7% toko yang diidentifikasi rentan sebenarnya telah diretas dalam waktu singkat. Angka ini dengan jelas menggambarkan seberapa cepat penjahat bereaksi ketika kerentanan yang dapat dieksploitasi dari jarak jauh muncul dan betapa berisikonya menunda penambalan di lingkungan produksi.

Setelah kode berhasil dieksekusi di server, langkah selanjutnya adalah menyuntikkan JavaScript skimming ke dalam template atau modul yang terkait dengan proses pembayaran. Ini memastikan bahwa skrip akan berjalan setiap kali pelanggan mengakses halaman pembayaran, menangkap data yang dimasukkan dan mengirimkannya secara tidak terlihat melalui saluran WebRTC hingga tim keamanan menemukan kerentanan dan membersihkan lingkungan secara menyeluruh.

Dari Magecart klasik hingga skimmer dengan WebRTC

Nama Magecart selama bertahun-tahun mencakup berbagai kelompok dan kampanye yang didedikasikan untuk mencuri data pembayaran dari toko online. Ini bukan hanya satu geng, melainkan seluruh ekosistem pelaku yang berbagi taktik dan berkembang seiring dengan semakin canggihnya langkah-langkah keamanan online.

Pada versi awalnya, skimmer Magecart hanya mengirim data melalui permintaan HTTP langsung ke domain yang dikendalikan oleh penyerang. Meninjau log akses atau menerapkan WAF dengan aturan yang wajar sudah cukup untuk mulai mengidentifikasi eksfiltrasi ini. Seiring waktu, dan dengan peningkatan pertahanan, para penjahat terpaksa mencari metode yang lebih tersembunyi.

Hal ini menyebabkan pengembangan teknik seperti image beacon , di mana informasi curian dikodekan dalam parameter unggahan gambar yang tampak tidak berbahaya, seperti GIF atau PNG. Meskipun lebih halus, pendekatan ini juga dapat dideteksi menggunakan kombinasi inspeksi lalu lintas keluar dan analisis pola.

Pada fase selanjutnya, beberapa kelompok mulai bereksperimen dengan WebSocket , mempertahankan saluran tetap antara peramban korban dan server perintah dan kontrol. Hal ini mempersulit deteksi berdasarkan permintaan HTTP konvensional, tetapi tetap terlihat oleh siapa pun yang dengan cermat memantau header dan tujuan koneksi ini.

Dalam konteks ini, peralihan ke WebRTC DataChannels merupakan langkah logis dalam perlombaan senjata antara penyerang dan pembela. Dengan bersembunyi di balik standar yang dirancang untuk aplikasi waktu nyata dan mengeksploitasi celah cakupannya di CSP dan perangkat jaringan, pelaku skimming mencapai tingkat kerahasiaan yang lebih unggul daripada generasi sebelumnya.

Perbedaan antara skimmer tradisional dan skimmer dengan WebRTC

Membandingkan skimmer klasik dengan skimmer berbasis WebRTC membantu memahami mengapa skimmer berbasis WebRTC menimbulkan ancaman serius bagi ekosistem e-commerce. Perbedaan pertama yang jelas terletak pada saluran keluaran data : sementara skimmer klasik menggunakan HTTP/HTTPS atau, paling banyak, WebSocket, pendekatan baru ini menggunakan UDP yang dienkripsi dengan DTLS melalui DataChannels.

Perbedaan utama kedua berkaitan dengan visibilitas alat keamanan . WAF, reverse proxy, atau IDS yang dirancang untuk memeriksa lalu lintas web bagus dalam mengenali pola berbahaya dalam HTTP, tetapi lebih sulit memeriksa konten sebenarnya dari saluran WebRTC terenkripsi, terutama jika solusi khusus belum diterapkan untuk tujuan tersebut.

Poin penting ketiga adalah peran CSP. Dalam kasus skimmer tradisional, Kebijakan Keamanan Konten (Content Security Policy/CSP) yang dirancang dengan baik dapat memblokir banyak upaya eksfiltrasi dengan membatasi koneksi ke domain yang tidak dikenal. Namun, dengan WebRTC, CSP standar tidak mengontrol pembuatan RTCPeerConnections, sehingga skimmer dapat membangun salurannya tanpa intervensi kebijakan.

Terakhir, ada faktor kematangan pertahanan : industri ini telah bertahun-tahun menyempurnakan tanda tangan, aturan, dan mekanisme perlindungan terhadap lalu lintas HTTP yang anomali. Sebaliknya, penyalahgunaan WebRTC untuk skimming relatif baru, sehingga belum ada tingkat spesialisasi atau aturan yang lebih canggih untuk mendeteksinya di lingkungan e-commerce.

Semua ini menempatkan para pelaku WebRTC skimmer dalam posisi menguntungkan untuk sementara waktu: para penyerang berada di depan , memanfaatkan fakta bahwa banyak organisasi masih belum meneliti secara teliti apa yang dilakukan kode JavaScript dengan API WebRTC di dalam browser.

Langkah-langkah perlindungan terhadap skimmer dengan WebRTC

Meskipun gambar tersebut mungkin tampak mengecewakan, beberapa langkah, jika digabungkan, dapat secara signifikan mengurangi risiko pemasangan dan keaktifan skimmer jenis ini di toko online Anda. Tidak ada solusi ajaib, tetapi ada serangkaian praktik terbaik yang koheren.

Solusi pertama dan paling jelas adalah segera menerapkan patch keamanan Magento dan Adobe Commerce yang memperbaiki PolyShell dan kerentanan eksekusi jarak jauh lainnya. Mempertahankan instance yang sudah usang ketika eksploitasi diketahui beredar—terutama jika muncul dalam daftar kerentanan yang umum dieksploitasi—sejujurnya, sama saja dengan bermain api.

Lini pertahanan penting lainnya adalah menerapkan pemantauan integritas JavaScript , terutama pada halaman sensitif seperti halaman pembayaran. Solusi khusus e-commerce dapat membandingkan kondisi skrip saat ini dengan versi referensi dan memberi peringatan saat blok baru, blok yang dienkripsi, atau blok yang melakukan panggilan ke domain yang tidak biasa terdeteksi.

Disarankan juga untuk secara berkala meninjau skrip pihak ketiga yang dimuat ke dalam proses pembayaran : widget obrolan, analitik, iklan, alat personalisasi, dll., karena ini dapat menandakan toko online yang curang . Setiap ketergantungan merupakan titik masuk potensial jika penyedia tersebut disusupi. Mengurangi jumlah skrip eksternal hingga seminimal mungkin membantu mengurangi potensi serangan.

Secara paralel, beberapa organisasi mulai menjajaki penggunaan arahan CSP berorientasi WebRTC di peramban yang secara eksperimental mendukungnya, seperti Chrome. Meskipun belum menjadi standar yang mapan, arahan ini dapat memberikan lapisan perlindungan tambahan di lingkungan yang terkontrol, selama arahan ini tidak menjadi satu-satunya lini pertahanan.

Terakhir, sangat disarankan untuk menerapkan mekanisme pemantauan waktu nyata untuk perilaku formulir pembayaran . Ini termasuk mencatat domain mana yang mencoba mengirimkan data dari browser, apakah koneksi yang tidak terduga dibuka, atau apakah RTCPeerConnections dimulai tanpa justifikasi fungsional yang jelas. Ketika eksfiltrasi ke tujuan yang tidak sah terdeteksi, sesi dapat dihentikan, otentikasi multi-faktor dapat diterapkan , IP dapat diblokir, dan prosedur respons insiden dapat diaktifkan.

Kesalahan umum yang menyebabkan bisnis e-commerce kehabisan stok.

Saat menganalisis insiden jenis ini, serangkaian pola kegagalan organisasi muncul yang membuat pekerjaan penyerang jauh lebih mudah. ​​Mengidentifikasi pola-pola ini adalah langkah pertama untuk mencegahnya di infrastruktur Anda sendiri.

Salah satu kesalahan paling umum adalah mempercayai CSP yang sangat ketat secara membabi buta , berpikir bahwa itu saja sudah cukup untuk memblokir setiap eksfiltrasi browser. Seperti yang telah kita lihat, kurangnya cakupan RTCPeerConnection dalam arahan standar meninggalkan celah yang dimanfaatkan oleh skimmer seperti eksploitasi WebRTC tanpa banyak usaha.

Kesalahan berulang lainnya adalah menunda penambalan kerentanan kritis ketika eksploitasi publik sudah ada dan kampanye aktif telah dilaporkan. PolyShell adalah contoh yang baik tentang bagaimana kelemahan yang diketahui dapat menjadi titik masuk besar-besaran jika toko membutuhkan waktu berminggu-minggu atau berbulan-bulan untuk memperbarui sistem mereka.

Sangat umum juga untuk terlalu bergantung pada pemantauan jaringan tradisional yang berpusat pada HTTP/HTTPS , tanpa melengkapinya dengan analisis integritas kode JavaScript dan tanpa memantau API khusus browser seperti WebRTC. Hal ini menghasilkan dasbor yang sangat menarik di mana "semuanya berwarna hijau," sementara pelaku skimmer terus mengirimkan data melalui saluran yang tidak diperiksa oleh siapa pun.

Terakhir, banyak tim teknis lupa untuk secara rutin memeriksa jalur seperti pub/media/custom_options atau direktori yang setara, yang justru dieksploitasi oleh penyerang dalam skenario serupa dengan PolyShell untuk mengunggah file berbahaya dan mempertahankan akses terus-menerus ke server.

Apa yang sudah diketahui tentang skimmer dan apa yang masih perlu diteliti lebih lanjut?

Informasi yang tersedia untuk umum memungkinkan kita untuk menggambarkan beberapa aspek dari WebRTC skimmer dengan cukup jelas, meskipun masih ada area abu-abu yang masih coba diklarifikasi oleh para peneliti.

Di antara data yang telah dikonfirmasi adalah penggunaan alamat IP 202.181.177.177 sebagai server C2 , port UDP 3479 untuk DataChannels, kredensial ICE yang dikodekan secara permanen (termasuk kata sandi klien 05l0TstonL9bYAdB04I6x2), sidik jari DTLS spesifik, dan pola SDP yang digunakan untuk mengaktifkan webrtc-datachannel dengan port SCTP 5000. Telah diverifikasi juga bahwa lebih dari setengah toko yang rentan terhadap PolyShell telah diretas dalam waktu singkat.

Yang masih belum diketahui adalah daftar lengkap perusahaan besar yang terdampak , karena tidak semuanya telah disebutkan secara publik. Juga belum jelas sejauh mana penggunaan WebRTC sebagai saluran eksfiltrasi telah meluas di antara semua kelompok Magecart, atau apakah saat ini terbatas pada subkelompok yang lebih maju secara teknis.

Demikian pula, katalog lengkap modul dan fungsionalitas tambahan yang mungkin diintegrasikan oleh malware ini tidak diketahui , misalnya, yang memungkinkannya untuk bergerak secara lateral di dalam infrastruktur, mencuri cookie sesi, atau memanipulasi aspek lain dari frontend. Masuk akal untuk berasumsi bahwa penyedia solusi keamanan khusus untuk Magento, WordPress, dan platform CMS lainnya sedang menyempurnakan mesin mereka untuk mendeteksi pola spesifik ini dan menawarkan aturan tanda tangan yang lebih komprehensif.

Yang pasti, peralihan ke WebRTC merupakan perubahan besar bagi praktik skimming e-commerce, memaksa toko dan penyedia keamanan untuk melihat jauh melampaui lalu lintas HTTP dan fokus pada apa yang sebenarnya dilakukan JavaScript di browser klien, terutama pada saat pembayaran yang kritis.

Mengingat semua hal di atas, jelas sekali bahwa WebRTC skimmer adalah ancaman besar berikutnya dalam pencurian data pembayaran online: mereka menggabungkan kerentanan kritis pada platform seperti Magento dan Adobe Commerce, mengeksploitasi celah dalam standar seperti CSP, dan bersembunyi di balik saluran terenkripsi yang sulit dipantau. Jika sebuah toko ingin menghindari kehilangan data pelanggannya yang beredar melalui "saluran samping" yang hampir tak terlihat ini, mereka perlu mengambil langkah serius seperti melakukan patching cepat, mengurangi skrip pihak ketiga, memantau integritas kode, dan terus-menerus mengamati perilaku browser yang sebenarnya, alih-alih hanya mengandalkan log HTTP.