IP exit Mullvad ternyata sangat mudah diidentifikasi

 (tmctmt.com)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Mullvad menempatkan beberapa IP exit pada satu server, tetapi penugasannya ditentukan secara deterministik berdasarkan kunci WireGuard, sehingga tidak berubah secara acak setiap kali terhubung
  • 3.650 data point yang dikumpulkan dari 9 server dengan berulang kali mengubah pubkey hanya dipetakan ke 284 kombinasi dari total 8,2 triliun kombinasi yang mungkin
  • IP exit tiap server berada pada posisi persentil yang mirip di dalam pool, dan satu kombinasi cenderung berada di sekitar persentil ke-81 di banyak server
  • Penyebabnya tampak berupa struktur pemilihan index IP exit dengan RNG berbasis seed yang menggunakan pubkey atau alamat tunnel sebagai seed dan ukuran pool sebagai batas atas
  • Jika rentang float dalam log IP saling tumpang-tindih, korelasi antarakun tetap dimungkinkan meski memakai server Mullvad yang berbeda, sehingga risiko anonimitas meningkat

Struktur yang membuat IP exit Mullvad menjadi vektor identifikasi

  • Mullvad menyediakan beberapa IP exit per server, dan dua pengguna yang terhubung ke server yang sama biasanya mendapatkan IP publik yang berbeda
  • Jumlah servernya 578, lebih sedikit dibanding 20.000 milik Proton VPN, sehingga pendekatan scale-up vertikal yang tidak menumpuk pengguna ke satu IP lebih menguntungkan untuk menghindari pemblokiran IP berlebihan dan pembatasan kecepatan
  • Namun IP exit tidak berubah secara acak setiap kali terhubung ke server, melainkan dipilih secara deterministik berdasarkan kunci WireGuard
  • Kunci WireGuard dirotasi setiap 1~30 hari, tetapi pada klien pihak ketiga tidak berotasi
  • Jika setiap server secara independen memberikan IP exit tetap, kombinasi IP dari beberapa server saja sudah bisa membedakan satu pengguna dari pengguna Mullvad lain

Kombinasi IP exit yang diamati di 9 server

  • Sebuah skrip dijalankan semalaman sambil berulang kali mengubah pubkey untuk mengumpulkan IP exit dari 9 server, menghasilkan 3.650 data point pubkey
  • Rentang IP exit tiap server diamati sebagai berikut
Hostname Start IP End IP # IPs
au-syd-wg-101 103.136.147.5 103.136.147.64 60
cl-scl-wg-001 149.88.104.4 149.88.104.14 11
de-ber-wg-007 193.32.248.245 193.32.248.252 8
dk-cph-wg-002 45.129.56.196 45.129.56.226 31
fi-hel-wg-201 185.65.133.10 185.65.133.75 66
us-lax-wg-001 23.234.72.36 23.234.72.126 91
us-nyc-wg-602 146.70.168.132 146.70.168.190 59
us-sjc-wg-302 142.147.89.212 142.147.89.224 13
za-jnb-wg-002 154.47.30.145 154.47.30.155 11
  • Jika ukuran pool server-server ini dikalikan, tampak ada lebih dari 8,2 triliun kombinasi IP exit yang mungkin
  • Semua pubkey yang benar-benar diuji ternyata hanya dipetakan ke salah satu dari 284 kombinasi
  • Dibanding jumlah kombinasi yang mungkin, jumlah kombinasi yang teramati sangat sedikit, yang menjadi petunjuk bahwa pemilihan IP per server tidak independen

Pola IP berbeda yang berada pada persentil yang sama

  • IP exit dapat dihitung posisi numeriknya berdasarkan seberapa jauh letaknya dari IP awal pool
  • Misalnya pada au-syd-wg-101, 103.136.147.53 memiliki index 1-based sebesar 49 jika dihitung mulai dari 103.136.147.5
  • Jika posisi IP dalam kombinasi yang diamati dibagi dengan ukuran pool tiap server, muncul rasio yang hampir sama di server yang berbeda
Server IP Position Pool size Ratio
au-syd-wg-101 103.136.147.53 49 60 0.816
cl-scl-wg-001 149.88.104.12 9 11 0.818
de-ber-wg-007 193.32.248.251 7 8 0.875
dk-cph-wg-002 45.129.56.220 25 31 0.806
fi-hel-wg-201 185.65.133.63 54 66 0.818
us-lax-wg-001 23.234.72.109 74 91 0.813
us-nyc-wg-602 146.70.168.179 48 59 0.813
us-sjc-wg-302 142.147.89.222 11 13 0.846
za-jnb-wg-002 154.47.30.153 9 11 0.818
  • Setiap IP berada pada persentil yang mirip dalam pool masing-masing, dan contoh di atas umumnya berada di sekitar persentil ke-81
  • Karena pola ini, Mullvad tampak hanya menetapkan IP exit yang posisinya saling berdekatan di semua server

Penyebab yang tampak seperti pemilihan acak berbasis seed

  • cl-scl-wg-001 dan za-jnb-wg-002 selalu berbagi index IP yang sama di seluruh 284 kombinasi IP yang diamati
  • Kesamaan kedua server itu adalah ukuran pool 11, dan ini cocok dengan struktur di mana pemanggilan bilangan acak dengan seed yang sama dan bounds yang sama menghasilkan keluaran yang sama
  • Jika RNG diinisialisasi dengan seed statis lalu mengambil angka acak pada rentang yang sama, hasil yang sama akan berulang
  • Mullvad tampaknya memilih index IP exit dengan RNG berbasis seed yang menggunakan pubkey atau alamat tunnel sebagai seed, lalu memasukkan ukuran pool sebagai nilai batas atas
  • Meski bounds berubah, entropy pool RNG tampaknya tidak terpengaruh, dan pada Rust ini sesuai dengan cara float yang sama dihasilkan pada pemanggilan pertama lalu dikalikan dengan bounds
  • Perilaku ini bisa dibayangkan secara sederhana sebagai min + round((max - min) * float), walau itu mungkin penyederhanaan yang cukup kasar
  • Karena karakteristik ini, walaupun ukuran pool berbeda, float yang berasal dari seed yang sama tetap dipetakan ke titik rasio yang mirip pada pool setiap server
  • Karena klien Mullvad ditulis dalam Rust, ada kemungkinan Rust juga menjadi bahasa backend, tetapi ini hanya dugaan berdasarkan implementasi klien
  • Sulit memprediksi secara tepat bagaimana random_range bekerja ketika bounds berubah, dan mudah mengira bahwa kenaikan bounds akan bercampur dengan entropy untuk menghasilkan angka lain, tetapi hasil pengamatan menunjukkan sebaliknya

Risiko anonimitas akibat korelasi log IP

  • Tersedia alat mullvad-seed-estimator untuk memperkirakan nilai float minimum dan maksimum yang mungkin dari kombinasi IP tertentu
  • Kumpulan IP tertentu pada tangkapan layar ditafsirkan sebagai nilai float di antara 0,2909~0,2943, dengan selisih 0,0034
  • Artinya, 0,34% pengguna Mullvad berbagi IP-IP tersebut, yang dalam perkiraan kasar 100.000 pengguna aktif setara dengan 340 orang
  • Ini memang tidak seunik perkiraan awal, tetapi akurasi di atas 99% tetap bukan angka yang rendah
  • Misalnya saat moderator forum memeriksa akun baru yang dicurigai sebagai sockpuppet dari pengguna yang diblokir sehari sebelumnya, meski kedua akun memakai server Mullvad yang berbeda, jika log IP mereka memiliki rentang float yang tumpang-tindih seperti 0.4334 - 0.4428 dan 0.4358 - 0.4423, kemungkinan keduanya adalah orang yang sama melebihi 99%
  • Korelasi yang sama juga bisa diterapkan pada log IP yang diperoleh melalui kebocoran data atau proses hukum, sehingga pengguna di balik VPN bisa kehilangan anonimitas

Cara melindungi diri

  • Disarankan tidak mengganti server lebih dari sekali untuk setiap pubkey
  • Di aplikasi Mullvad, Anda bisa logout untuk memaksa rotasi pubkey

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News

  • Saya adalah co-CEO sekaligus salah satu pendiri yang bekerja di Mullvad. Sebagian perilaku yang disebut di tulisan itu memang disengaja dan sebagian tidak, dan penyebabnya juga tidak persis seperti penjelasan di posting blog tersebut
    Sebagai mitigasi, patch untuk perilaku yang tidak disengaja sudah kami uji di sebagian infrastruktur, jadi jika Anda mencoba mereproduksinya hari ini, hasilnya bisa membingungkan
    Kami juga akan menilai ulang apakah perilaku yang disengaja itu masih bisa diterima, karena di sini ada trade-off antara berbagai aspek privasi dan pengalaman pengguna
    Pemahaman ini adalah penilaian saya saat ini, disusun sambil menulis komentar ini setelah mengetahui hal tersebut satu jam lalu dan langsung membahas respons dengan tim operasional, jadi bisa saja berubah
    Bagi para peneliti keamanan, jika menemukan masalah keamanan atau privasi, mohon beri tahu admin atau vendor terlebih dahulu meskipun Anda tetap berencana mengungkapkannya segera

    • Klien Mullvad secara default tampaknya memiliki interval rotasi kunci 72 jam, dan klien CLI juga bisa dipakai di sebagian besar situasi yang menggunakan WireGuard native dengan sedikit penyesuaian
      Anda bisa mengeceknya dengan mullvad tunnel get dan mengubahnya dengan mullvad tunnel set rotation-interval , dan ini juga mitigasi yang disukai dalam tulisan tersebut
      Secara pribadi, saya tidak menganggap IP semi-statis sebagai masalah besar. Tujuannya adalah mencegah pengawasan tingkat jaringan oleh ISP dan pemerintah, dan beberapa penyedia bahkan menjual IPv4 statis sebagai fitur
      Dalam VPN privasi, semakin kecil ruang IP, semakin banyak pengguna yang bisa tercampur di balik satu IP yang terlihat dari luar, jadi itu juga ada kelebihannya. Jika digabung dengan teknologi seperti DAITA yang memasukkan traffic dummy ke dalam tunnel dan entry point multihop, menurut saya itu benar-benar bisa membuat pengawas yang memantau netflow sepanjang hari menjadi jauh lebih kesulitan
    • Saya Carl, CEO Obscura dan salah satu mitra Mullvad. Ini temuan yang menarik, tetapi seperti kata kfreds, akan lebih baik jika vendor diberi tahu sebelum dipublikasikan
      Temuan inti berupa korelasi posisi dalam pool IP antarserver tampaknya memang mencakup perilaku yang tidak disengaja. Dari pengalaman saya bekerja dengan tim Mullvad, saya rasa ini akan segera ditangani
      Jika Anda ingin “identitas” yang berbeda, Anda perlu merotasi kunci WireGuard atau memakai kunci yang berbeda
      Di artikel itu disebut, “setiap kali terhubung ke server, exit IP tidak dipilih secara acak melainkan dipilih secara deterministik berdasarkan kunci WireGuard, dan kunci itu dirotasi setiap 1~30 hari. Jika memakai klien pihak ketiga, kunci tidak akan dirotasi.” Namun WireGuard, secara desainhttps://www.wireguard.com/protocol/, adalah protokol tanpa koneksi, jadi tidak ada konsep koneksi; yang ada hanya handshake rekeying setiap 2~3 menit saat traffic mengalir
      Jika bahkan dengan kunci WireGuard yang sama exit IP berubah setiap kali “terhubung”, misalnya setiap handshake rekeying atau setiap 15 menit, maka di lapisan transport hampir semua koneksi di dalam tunnel selain QUIC akan putus dan harus dibuat ulang, dan di lapisan aplikasi, layanan yang curiga terhadap “cookie yang sama, IP baru” akan memicu logout, CAPTCHA, atau skor risiko
      Keduanya memberikan pengalaman pengguna yang buruk, dan lebih buruk lagi, justru bisa membuat sidik jari pengguna lebih unik, seperti “orang ini terus tersambung ulang dari IP berbeda, jadi dia pengguna Mullvad”

  • Contoh “admin forum mencurigai apakah ini akun alternatif dari pengguna yang diblokir sehari sebelumnya, lalu memeriksa log IP dan melihat bahwa meski memakai server Mullvad yang berbeda, kedua akun dipetakan ke rentang pecahan mengambang yang tumpang tindih 0.4334~0.4428 dan 0.4358~0.4423, sehingga bisa dianggap orang yang sama dengan probabilitas di atas 99%” memberi kesan seperti beginilah bentuknya jika badan intelijen merancang VPN

    • Saya tidak tahu kenapa. Jika badan intelijen merancang VPN, mereka tidak akan bergantung pada statistik exit node, mereka akan langsung mencatat log semua IP yang terhubung ke VPN
      Lagi pula, pendekatan ini bergantung pada pengguna yang memilih server berbeda, jadi makin tidak masuk akal
    • Rasanya suatu hari nanti akan terungkap bahwa Cloudflare juga punya hubungan dengan badan intelijen. Jika solusi untuk “DDoS mendadak” adalah menaruh website di belakang Cloudflare, jadi penasaran juga siapa yang mampu melakukan serangan mendadak seperti itu
    • Tetap saja ada detail kecil bahwa mereka tidak menyimpan log
      Menurut saya ini masalah besar, dan memungkinkan analisis korelasi di antara beberapa exit node VPN, tetapi hanya itu. Ini tidak otomatis memungkinkan identifikasi pengguna
      Namun ini memang sangat menurunkan tingkat kesulitannya, meski syarat yang diperlukan tetap tinggi. Semoga segera diperbaiki
      Sulit dipercaya bahwa kesalahan model “mari buat ini dari nilai sensitif seperti hash” masih terjadi, bahkan di Mullvad. Rasanya kenapa tidak dibuat acak saja
    • Mullvad sudah ada beberapa tahun sebelum bocoran Snowden, dan tidak muncul di dokumen-dokumen itu
      Tentu masih ada badan intelijen lain, tetapi pihak itulah yang paling patut dikhawatirkan. Mereka bisa saja mengoperasikannya langsung, tahu ide seperti ini dan menirunya, atau punya akses ke layanan yang dijalankan lembaga mitra. Kalau tidak, itu bukan ancaman bagi saya
      Lagi pula, tidak ada contoh publik pengguna Mullvad yang dianonimkan balik lewat VPN itu sendiri; yang diketahui justru kasus ditemukan karena kegagalan opsec lain. Jika badan intelijen punya kemampuan ini, sulit dipercaya mereka menyimpan data hampir 20 tahun tanpa memakainya
    • Jika badan intelijen mengendalikan VPN, mereka tinggal mengawasi traffic secara langsung. Tidak ada insentif untuk mempermudah pengamat eksternal menebak pengguna mana keluar lewat IP exit tertentu

  • Saya tidak mengerti bagaimana angka “probabilitas di atas 99%” bisa muncul hanya dari angka-angka di tulisan itu. Bahkan jika diasumsikan kuat bahwa seed dari IP terblokir pertama dan seed kedua sama-sama berada di rentang 0.4423~0.4358, itu hanya berarti rentang ini mencakup 0,65% dari seluruh pengguna Mullvad
    Jika ada 100 ribu pengguna, itu berarti 650 orang, jadi yang dieliminasi adalah lebih dari 99% “tersangka”, bukan mengidentifikasi satu individu dengan akurasi di atas 99% di berbagai exit IP
    Jika dilihat secara Bayes, tumpang tindih seed potensial memang menjadi bukti kuat bahwa dua IP itu milik orang yang sama, atau setidaknya akun Mullvad yang sama, tetapi sepertinya itu bukan yang dimaksud penulis

    • Jika forumnya cukup besar, misalnya ada 1000 pengguna aktif dan 1 pengguna baru per hari, saya jadi ingin tahu berapa peluang bahwa sehari setelah seseorang diblokir, ada orang yang mendaftar memakai VPN ini dan kebetulan punya rentang IP serupa
      Untuk kebanyakan website kecil, ini menjadi bukti yang cukup kuat

  • Tujuan VPN tidak mencakup membuat pengguna anonim terhadap situs yang dikunjungi, jadi tidak mengherankan jika Mullvad tidak memaksakan exit IP yang unik. Pengguna yang menginginkan anonimitas seharusnya memakai jaringan seperti Tor

    • Saya tidak paham kenapa tidak bisa. Tidak ada alasan tujuan layanan VPN tertentu tidak bisa seperti itu
    • Bukankah Tor adalah proyek pemerintah AS dan pernah ditunjukkan bisa dianonimkan balik?
    • Justru itulah tujuan VPN publik
      Jika memakai VPN publik, orang berharap tidak ada yang tahu siapa yang mengirim permintaan itu, termasuk IP ujungnya
      Dengan logika itu, VPN tidak boleh dipakai untuk torrent. Karena berarti ia tidak boleh menganonimkan IP ujung. Padahal dalam praktiknya, itu bekerja sangat baik untuk torrent
      Kalau yang dimaksud VPN privat, Mullvad bukan itu

  • Saya sudah lama memakai Mullvad, dan selama itu legal di negara saya, saya akan terus membeli dan memakai layanan VPN Mullvad dengan kartu kredit atas nama saya sendiri
    VPN bukan anonimitas 100%, dan memang tidak dirancang untuk itu. Sebaliknya, VPN dimaksudkan memberi tingkat privasi tertentu bagi orang dewasa yang taat hukum
    Kebanyakan orang akan merasa tidak nyaman jika rekan kerja dan tetangga tahu kehidupan pribadi mereka, apa yang mereka sukai, apa yang mereka beli, dan apa yang mereka lakukan. Karena itu, kebanyakan orang perlu memakai VPN untuk melindungi privasi mereka
    Secara definisi, “kebanyakan orang” tidak menginginkan atau mengharapkan anonimitas 100% di internet; mereka hanya ingin sedikit privasi dalam kehidupan pribadi dan relasi mereka
    VPN tidak melindungi penjahat yang ingin melakukan kejahatan online sambil tetap 100% anonim dari pemerintah, dan memang bukan untuk itu. Pembedaan ini penting. “Kebanyakan orang” bukan penjahat, dan mereka tidak punya ekspektasi tidak realistis seperti itu terhadap Mullvad atau penyedia VPN lainnya

    • VPN memang bukan anonim, hanya saja orang berpura-pura begitu. Namun temuan laporan ini tetap menunjukkan faktor yang membuat identifikasi pengguna lebih mudah daripada yang diperkirakan
      Laporan itu tidak bisa dibuang hanya dengan logika di atas. Temuannya sendiri tetap valid

  • Ada hal yang kurang. Saya penasaran apakah mereka menghubungi Mullvad. Akan menarik juga melihat bagaimana tim keamanan meresponsnya

    • Setahu saya tidak ada kontak, dan saya sudah mengeceknya ke tim operasional maupun tim dukungan. Jika saya salah, saya akan memperbarui komentar ini
      Belakangan saya merasa menyesal menulis komentar ini. Sebenarnya tidak perlu, tetapi sekarang kalau dihapus malah terlihat aneh
    • Bukan, tetapi komentar teratas yang paling banyak direkomendasikan di posting ini adalah tanggapan dari salah satu pendiri Mullvad

  • Saya merasa aneh bahwa orang berharap VPN akan mirip Tor
    Jika dijabarkan begitu, itu memang terdengar tidak masuk akal, dan juga perlu diingat bahwa bahkan pengguna Tor pun bisa dianonimkan balik jika exit node dikendalikan

    • Tidak mengherankan, karena sebagian besar VPN konsumen besar dalam pemasarannya mengisyaratkan “privasi” seolah itu berarti anonimitas
    • Bukankah bagian dari desain Tor adalah melewati beberapa relay node, sehingga bahkan exit node pun tidak bisa melihat IP asal?
    • Mungkin itu bukan ekspektasi yang seharusnya, tetapi orang tetap cenderung berpikir bahwa jika memungkinkan, mereka akan berusaha melakukan apa yang bisa dilakukan untuk memberi privasi

  • Bagian “exit IP tidak diacak setiap kali terhubung, melainkan dipilih secara deterministik berdasarkan kunci WireGuard, dan kunci ini dirotasi setiap 1~30 hari. Jika memakai klien pihak ketiga, kunci tidak pernah dirotasi” agak membingungkan
    Jika metode lengkapnya ada di repositori, saya tidak paham apa yang mencegah pihak ketiga melakukan rotasi kunci seperti klien aplikasi resmi

    • Klien pihak ketiga itu termasuk, misalnya, driver WireGuard di kernel Linux. Tidak mungkin driver jaringan diberi tanggung jawab untuk memitigasi serangan terhadap satu layanan komersial tertentu
    • Yang terutama menghambat adalah mengetahui bahwa itu memang perlu dilakukan

  • Penulis berhasil menemukannya dengan baik, dan saya cukup percaya bahwa ini memang kesalahan Mullvad. Cukup mengejutkan hal sesederhana ini bisa lolos, walau saya juga merasa saya sendiri mungkin bisa melewatkannya
    Kalau tidak melihat korelasi IP antarbeberapa server, awalnya saya juga bertanya-tanya kenapa IP pengguna dipertahankan stabil di satu server. Namun penjelasan penulis bahwa ini meniru VPN lain yang biasanya punya satu IP per server memang masuk akal
    Jika pengguna menemukan server yang bisa mengakses layanan tertentu, ada keuntungan bahwa saat tersambung lagi ke server itu mereka mungkin mendapat IP yang sama dan kembali berfungsi
    Namun korelasi IP antarbeberapa server seharusnya diperbaiki dengan cara seperti rand.seed(user_pub_key + server_id)

    • Sebaliknya, jika karena tetangga yang berisik pada IP yang sama seorang pengguna diblokir oleh layanan tertentu, bukankah itu berarti pengguna tidak punya cara untuk menghindarinya?

  • Saya bekerja di IPinfo. Kami memang bergerak di bisnis deteksi VPN, tetapi sejujurnya saya ingin memberi Mullvad manfaat dari keraguan
    Mullvad adalah satu dari tiga penyedia VPN yang tidak mencoba mengirimkan data geolokasi yang tidak akurat kepada penyedia geolokasi IP seperti kami. Saya yakin masalah ini juga akan mereka perbaiki

    • Dua sisanya siapa?