Penyerang Dapat Mengekspos VPN Berbasis Routing
(leviathansecurity.com)- TunnelVision(CVE-2024-3661) menyalahgunakan fitur lama DHCP untuk mengalihkan trafik pengguna ke luar tunnel VPN; paket tersebut tidak dienkripsi oleh VPN
- Penyerang dapat menyuntikkan route yang lebih spesifik lewat DHCP option 121 untuk membuat jalur yang diprioritaskan dibanding antarmuka virtual VPN, lalu mengirim trafik melalui antarmuka fisik
- Serangan dimungkinkan jika target menerima lease DHCP yang dikendalikan penyerang dan klien mengimplementasikan option 121; dalam pengujian, Windows, Linux, iOS, dan macOS terdampak, sementara Android tidak
- Kanal kontrol VPN tetap tersambung sehingga pengguna melihatnya sebagai koneksi aktif; dalam kasus yang diamati, kill switch juga tidak mampu mencegah kebocoran trafik
- Network namespace di Linux dapat menjadi solusi yang kuat, tetapi mitigasi berbasis firewall dapat menimbulkan denial of service selektif dan side channel untuk menyimpulkan tujuan trafik
Decloaking VPN yang dibuat TunnelVision
- TunnelVision adalah teknik jaringan yang memaksa trafik pengguna keluar dari tunnel dengan melewati enkapsulasi VPN
- Penyerang dapat menggunakan DHCP(Dynamic Host Configuration Protocol) untuk membuat paket target dikirim tanpa dienkripsi oleh VPN
- Kanal kontrol VPN tetap dipertahankan, sehingga pengguna masih terlihat seolah-olah terhubung ke VPN; efek ini disebut decloaking
- Teknik ini mungkin sudah bisa dilakukan sejak 2002, dan setelah publikasi, telah dikonfirmasi adanya informasi bahwa riset terdahulu tentang DHCP option 121 dan dampaknya pada VPN sudah ada setidaknya sejak 2015
- 2015: Hardening OpenVPN for Def Con
- 2016: Samy Kamkar's
- 2017: Jomo's Mastodon
- 2023: Lowend talk thread
Mengapa routing VPN menjadi permukaan serangan
- VPN membuat tunnel untuk trafik antara perangkat host dan server di jaringan lain, dan klien VPN mengenkripsi serta mendekripsi trafik pada antarmuka jaringan virtual
- Konfigurasi yang mengirim seluruh trafik melalui VPN disebut full-tunnel VPN, sementara konfigurasi dengan pengecualian seperti jaringan lokal disebut split-tunnel VPN
- Karena VPN harus mempertahankan koneksi ke server, diperlukan route pengecualian yang mengirim trafik menuju IP server VPN melalui antarmuka fisik
- Tabel routing menentukan jalur trafik berdasarkan tujuan, dan pada sebagian besar network stack, CIDR prefix length yang lebih spesifik mendapat prioritas lebih tinggi
- Route
/32diprioritaskan dibanding/24atau/0 - Banyak full-tunnel VPN mengirim trafik ke antarmuka VPN dengan route
0.0.0.0/0atau dua route/1
- Route
Penyuntikan route menggunakan DHCP option 121
- DHCP secara dinamis menyediakan lease alamat IP ke perangkat jaringan lokal, dan melalui options juga menyampaikan konfigurasi seperti gateway default dan server DNS
- Alur umumnya adalah klien menyiarkan
DHCPDISCOVER, lalu server menawarkan lease berbatas waktu denganDHCPOFFER - DHCP option 121 yang diperkenalkan dalam RFC 3442 adalah fitur classless static routes, yang memungkinkan server DHCP menambahkan route statis ke tabel routing klien
- Option 121 tidak memungkinkan server DHCP menentukan langsung perangkat antarmuka jaringan untuk route yang akan dipasang
- Server DHCP menentukan rentang CIDR dan router
- Klien secara implisit memilih antarmuka yang sedang berkomunikasi dengan server DHCP sebagai antarmuka untuk route tersebut
- Karena perilaku ini, trafik pada route yang disuntikkan dapat keluar melalui antarmuka jaringan fisik yang berkomunikasi dengan server DHCP, bukan antarmuka virtual VPN
Syarat serangan dan cara pelaksanaannya
- Serangan TunnelVision membutuhkan dua syarat
- Host target harus menerima lease dari server DHCP yang dikendalikan penyerang
- Klien DHCP pada host target harus mengimplementasikan DHCP option 121
- Penyerang di jaringan yang sama dapat menjadi server DHCP target dengan berbagai cara
- Melakukan serangan DHCP starvation terhadap server DHCP asli, lalu merespons klien baru
- Merespons broadcast
DHCPDISCOVERlebih dulu dan menyalahgunakan perilaku klien DHCP yang memilih offer pertama - Mencegat trafik antara server DHCP asli dan klien dengan ARP spoofing, lalu menunggu pembaruan lease
- Penyerang menjalankan server DHCP di jaringan yang sama dengan pengguna VPN target dan mengatur dirinya sendiri sebagai gateway
- Setelah itu, penyerang menambahkan route arbitrer ke tabel routing pengguna VPN melalui DHCP option 121, lalu memasukkan route yang lebih spesifik daripada
/0milik VPN agar diprioritaskan dibanding antarmuka virtual VPN- Dengan mengatur beberapa route
/1, penyerang dapat mereproduksi aturan seluruh trafik0.0.0.0/0yang digunakan sebagian besar VPN - Penyerang dapat memilih alamat IP mana yang masuk ke tunnel VPN dan alamat mana yang pergi ke antarmuka yang berkomunikasi dengan server DHCP penyerang
- Dengan mengatur beberapa route
- Ini juga dapat diterapkan pada koneksi VPN yang sudah tersambung, dan dengan mengatur waktu lease DHCP yang singkat, pembaruan tabel routing dapat dipicu lebih sering
PoC dan skenario eksperimen
- Materi yang dipublikasikan adalah sebagai berikut
- Video proof of concept: https://www.youtube.com/watch?v=ajsLmZia6UU
- Lab Setup Code: https://github.com/leviathansecurity/TunnelVision
- DHCP Server image: https://drive.google.com/file/d/1WLJGs3ZUypf6hLh5WL4AJmsKdUOZo5yZ
- Lingkungan eksperimen dikonfigurasi untuk merepresentasikan beberapa skenario serangan
- Ketika penyerang telah mengompromikan server DHCP atau access point
- Ketika administrator jahat memiliki dan mengonfigurasi infrastruktur secara langsung
- Ketika penyerang memasang AP nirkabel evil twin di lokasi fisik seperti kafe atau kantor
- Setelah ArcaneTrickster dipublikasikan di masa depan, penyerang yang merupakan host tetangga di LAN yang sama tetapi bukan berada pada posisi jaringan istimewa juga dapat disimulasikan
Sistem operasi dan VPN yang terdampak
- Dalam pengujian, sistem operasi yang mengimplementasikan klien DHCP sesuai spesifikasi RFC dan mendukung route DHCP option 121 terdampak
- Dampak teramati: Windows, Linux, iOS, macOS
- Pengecualian: Android tidak terdampak karena tidak mendukung DHCP option 121
- VPN yang mengandalkan perlindungan trafik host hanya pada aturan routing rentan
- Administrator sistem yang menjalankan server VPN sendiri juga kemungkinan rentan jika belum memperkuat konfigurasi klien VPN
- Kekuatan algoritme enkripsi tidak berpengaruh
- TunnelVision tidak membobol protokol VPN itu sendiri seperti WireGuard, OpenVPN, atau IPsec
- Metodenya adalah mengubah konfigurasi routing pada network stack sistem operasi agar pengguna tidak memakai tunnel VPN
Perbaikan dan mitigasi
- Network namespace di Linux dapat memperbaiki perilaku ini sepenuhnya
- Dokumentasi WireGuard menunjukkan cara memproses trafik aplikasi yang harus memakai VPN di namespace terpisah, lalu mengirimkannya ke namespace lain yang memiliki antarmuka fisik
- Belum jelas apakah ada solusi sekuat itu di Windows, macOS, dan sistem operasi lain
- Sebagian penyedia VPN menggunakan mitigasi yang memblokir semua trafik inbound dan outbound pada antarmuka fisik dengan aturan firewall
- Pengecualian untuk DHCP dan IP server VPN diperlukan demi mempertahankan koneksi LAN dan server VPN
- Deep packet inspection juga dapat digunakan untuk hanya mengizinkan DHCP dan protokol VPN, tetapi kemungkinan ada penalti performa
- Mitigasi firewall membuat denial of service selektif pada trafik yang menggunakan route DHCP dan menambahkan side channel
- Penyerang dapat menganalisis perubahan volume trafik terenkripsi VPN untuk membuktikan secara statistik apakah pengguna target mengirim trafik ke tujuan tertentu
- Penyerang dapat mencocokkannya dengan daftar yang telah ditentukan, melakukan pemblokiran selektif sebagai mekanisme sensor, atau menggunakan pemblokiran ruang IP seperti pencarian biner untuk menemukan koneksi saat ini dalam waktu logaritmik
- Mengabaikan option 121 saat menggunakan VPN juga memungkinkan, tetapi fitur ini bisa diperlukan untuk konektivitas jaringan yang sah sehingga dapat menyebabkan gangguan koneksi
- Jika mitigasi ini bersifat opsional, penyerang dapat menolak akses jaringan untuk mendorong VPN atau pengguna mengaktifkan kembali option 121
- Hotspot atau VM juga dapat membantu mitigasi
- LAN yang dikunci kata sandi dan dikendalikan perangkat seluler membantu mencegah akses penyerang ke jaringan lokal
- VM bekerja serupa jika adapter jaringannya bukan dalam bridged mode
Tindakan yang diperlukan bagi pengguna dan operator
- Untuk trafik sensitif, hindari menggunakan jaringan yang tidak tepercaya; jika tidak dapat dihindari, gunakan penyedia VPN yang memiliki mitigasi efektif terhadap TunnelVision
- Meskipun terjadi decloak VPN, saat mengakses situs HTTPS, sebagian besar data pengguna tidak terlihat oleh penyerang jaringan lokal, tetapi tujuan dan protokol dapat terekspos
- Jika menggunakan VPN perusahaan di kafe, hotel, bandara, dan tempat serupa, administrator jaringan harus memberi tahu risikonya dan menyarankan agar sebisa mungkin dihindari
- Jika tidak praktis, arahkan penggunaan VPN yang telah menerapkan mitigasi atau perbaikan
- Opsi lain adalah menggunakan hotspot tepercaya lalu terhubung ke VPN, atau menjalankan VPN di dalam VM yang menerima lease dari server DHCP virtual
- Perusahaan yang mengoperasikan jaringan sendiri atau site-to-site VPN harus memeriksa switch dan mengaktifkan perlindungan Layer 2 seperti DHCP snooping dan perlindungan ARP
- Perlindungan ini membantu mengurangi server DHCP rogue, tetapi tidak menghapus skenario administrator jahat
- Menerapkan HTTPS atau protokol terenkripsi lain pada resource internal membantu mencegah kebocoran data pengguna VPN yang mengakses dari jaringan tidak tepercaya
- Penyedia VPN dapat menambahkan fitur firewall pada klien untuk memblokir paket outbound yang keluar melalui antarmuka jaringan, tetapi pengguna jadi tidak dapat berinteraksi dengan resource jaringan lokal
- Klien full-tunnel VPN untuk Linux harus mempertimbangkan isolasi menggunakan network namespace
- Maintainer sistem operasi harus mempertimbangkan penambahan atau penguatan fitur terkait network namespace pada sistem operasi selain Linux
- Sebuah library adversarial infrastructure bernama ArcaneTrickster untuk riset keamanan LAN dan demonstrasi serangan nyata sedang dikembangkan dan rencananya akan dipublikasikan nanti
1 komentar
Komentar Hacker News
Ini hanya sedikit variasi dari serangan PoisonTap Samy Kamkar pada 2016. Serangan itu melakukan hal yang sama dengan adaptor jaringan USB/Thunderbolt; jika dicolokkan ke perangkat korban dan mengiklankan dua rute yang lebih spesifik seperti 0.0.0.0/1 dan 128.0.0.0/1, ia bisa mengambil alih semua traffic dengan prioritas di atas interface sistem lain, terlepas dari urutan interface: https://github.com/samyk/poisontap
Mungkin ada preseden lain juga, tetapi ini contoh yang sangat terkenal. Judul artikel mengatakan semua klien VPN terdampak, tetapi seperti yang diakui dalam isi artikel, banyak klien VPN memasang aturan firewall yang memblokir traffic dari/ke interface fisik
VPN yang mengusung anonimitas identitas, atau yang anonimitas semacam itu penting, umumnya menerapkannya. Banyak pengaturan mungkin tidak aktif secara default, tetapi rasanya akan lebih produktif jika mereka mendokumentasikan berapa persen solusi VPN pribadi/komersial/perusahaan besar yang mengaktifkan ini secara default
Penjelasan untuk pembaca umum memang bagus, tetapi melihat bahwa banyak klien mencegah sebagian besar kebocoran data dengan aturan firewall seperti ini dan tidak mengakui preseden di bidang ini, judulnya terasa agak dilebih-lebihkan
Saya hampir menyemburkan minuman saat melihat istilah “serangan kanal samping”
Edit: setelah dilihat, NordVPN setidaknya di mac tampaknya tidak memiliki aturan firewall default seperti itu, jadi sepertinya rentan terhadap serangan ini
Saya tidak mengerti kenapa artikel ini begitu panjang
DHCP Option 121 memungkinkan server DHCP menetapkan aturan routing untuk rentang CIDR tertentu, dan karena prefix-nya lebih panjang, prioritasnya lebih tinggi daripada aturan default 0.0.0.0/0
Setengah informasi VPN di internet ditulis oleh penyedia VPN, dan tidak akurat atau tidak cukup teknis untuk menjelaskan bagaimana sebenarnya cara kerjanya
Saya tadinya ingin menaruh kalimat “kalau sudah tahu bagian ini, lompat ke bagian POC” sebagai tautan di pendahuluan; akan saya perbarui agar lebih terlihat
Ini dugaan saya hanya berdasarkan komentar di atas, tanpa membaca artikelnya
Saya merasa pernah membaca serangan ini dari penulis lain sebelumnya, jadi saya mencarinya, dan setelah menerobos spam vendor VPN yang membanjiri hasil pencarian, saya menemukan karya sebelumnya [1]
Artikel kali ini membahas lebih dalam cara mengeksploitasi cacatnya, dan juga ada kode yang membantu untuk proof of concept
1: https://www.usenix.org/conference/usenixsecurity23/presentat...
Namun, kedua teknik dalam paper Agustus 2023 itu tidak mendorong rute melalui DHCP option 121. Jika rute didorong lewat DHCP, dampaknya jauh lebih besar dari posisi penyerang yang sama. Misalnya, posisi yang dapat membagikan lease IP dari rentang non-RFC1918 atau memalsukan respons DNS
Model ancamannya adalah penyerang acak entah bagaimana bisa menjadi server DHCP di LAN saya; kemungkinannya kecil, tetapi bukan mustahil
Sebaliknya, kalau Anda memakai perangkat gateway yang disediakan ISP, ceritanya berbeda
Itu adalah poin jual nomor satu bagi sebagian besar produk VPN
Dalam kasus ini, respons yang benar adalah memakai koneksi 4G/5G dan tidak terhubung ke jaringan mencurigakan yang tidak dipercaya
Fakta bahwa di rumah biasa DHCP disediakan oleh router dan karena itu biasanya merespons lebih dulu hanyalah hal sekunder. Perangkat jahat mana pun di dalam jaringan dapat memakai kerentanan ini
Di Linux, ini juga bisa dimitigasi dengan memasukkan interface VPN ke VRF. Misalnya, systemd-networkd mendukung ini secara bawaan
Yang perlu diperhatikan adalah saat VRF diaktifkan, entri ip rule untuk l3mdev ditetapkan ke 1000, sedangkan aturan traffic lokal ditetapkan ke 0. Aturan lokal harus dipindahkan ke 1000 atau lebih
“Serangan” ini hanyalah penggunaan DHCP option 121 secara cerdik. Ini serangan yang valid terhadap konfigurasi klien yang sangat rusak
Mengubah default route atau menimpanya dengan dua rute /1 lalu menambahkan host route ke endpoint VPN bukanlah cara yang aman. Untuk mengisolasi traffic yang dienkapsulasi dengan benar dari jaringan bawah, harus memakai policy-based routing. Contohnya Linux network namespace, FreeBSD vnet, dan OpenBSD rdomains
Pendekatan memaksakan gabungan packet filter dan “kill switch” di user space sudah rusak sejak desainnya, dan menunjukkan betapa penyedia hosting VPN umum tidak memahami atau tidak peduli pada hal yang bahkan mereka sebut kompetensi inti mereka. Ini lagi-lagi masalah lama “menginventarisasi hal-hal buruk”
Ini bukan hal baru
Saya lebih khawatir pada orang-orang yang sistemnya mengaktifkan IPv6 tetapi memakai layanan VPN khusus IPv4
Itu benar-benar bisa berakhir sangat buruk
Ada banyak cara untuk melewati VPN dari perangkat klien. Jadi saat VPN diperlukan, saya lebih memilih menempatkan router di antara klien dan internet, yang mengakhiri tunnel VPN dan tidak memiliki rute lain.
Router perjalanan seperti ini sangat mudah dikonfigurasi, bisa dibawa ke mana saja, dan saya memang melakukannya.
Misalnya ada router Wi-Fi “work” yang selalu menjaga koneksi VPN ke intranet kantor, ada Wi-Fi “Australia” yang menghubungkan VPN ke server Australia setiap kali ingin menonton TV Australia, dan terakhir ada Wi-Fi internet rumah biasa.
Ini sangat mudah dilakukan hanya dengan beberapa router Wi-Fi lama, dan router rumahan murah saat ini tampaknya juga sudah mendukung VPN sampai tingkat tertentu. Selain memusatkan konfigurasi VPN sehingga mengurangi ruang untuk kesalahan, keuntungan besarnya adalah perangkat apa pun bisa memakai VPN cukup dengan tersambung ke Wi-Fi tersebut.
Saya memakai beberapa router tua untuk hal seperti ini, tetapi sebetulnya rasanya ada pasar untuk produk berupa satu router rumahan yang membuat koneksi VPN ke berbagai lokasi di dunia dan menyediakan jaringan Wi-Fi berbeda untuk tiap lokasi. Gunanya agar TV/Roku/iPad dengan mudah terlihat seperti mengakses dari wilayah lain.
Namun jika ada perangkat yang tidak tepercaya di LAN dan Anda memakai DHCP, perangkat itu bisa menggunakan teknik ini untuk mengintip traffic yang tidak terenkripsi*. Meski begitu, karena gateway menyembunyikannya, IP asli tidak akan ditemukan.
Tempat serangan ini paling realistis adalah situasi seperti Wi-Fi kafe. Di tempat seperti itu, kecil kemungkinan orang membawa router sendiri.
Di sini “traffic yang tidak terenkripsi” berarti traffic yang tidak dienkapsulasi untuk dikirim ke penyedia VPN. Saat ini sebagian besar sudah HTTPS, jadi isi traffic itu sendiri kemungkinan tetap terenkripsi.
Bagi orang teknis, ini seharusnya cukup jelas, tetapi bagus sebagai penjelasan pengantar tentang networking dan VPN. Saya beberapa kali mengonfigurasi VM gateway VPN Linux, dan arsitektur yang hanya bergantung pada routing table selalu terasa rapuh, terutama saat berjalan di mesin yang sama yang memakai koneksi tersebut.
Selain network namespace dan router gateway VPN fisik, arsitektur berbasis VM juga bisa menyelesaikan masalah ini. Di homelab saya, firewall memblokir traffic tak terduga yang keluar dari VM gateway VPN. Perangkat di VLAN VPN tidak bisa terhubung langsung ke luar, dan VM gateway memiliki VLAN terpisah untuk koneksi eksternal.
Untuk solusi pribadi, QubesOS memungkinkan konfigurasi serupa dengan cukup minim gesekan, tetapi tetap membutuhkan pengetahuan teknis lebih banyak dibanding OS umum.
Bagian bahwa “Android adalah satu-satunya yang tidak terdampak karena tidak mengimplementasikan dukungan DHCP option 121” menarik.
Saya penasaran apakah Google mengetahui masalah ini dan sengaja mengambil keputusan tersebut, atau sepenuhnya kebetulan.
Dugaan saya, tim networking Android sangat mendukung IPv6. Mereka tampaknya tidak terlalu tertarik pada fitur pinggiran IPv4 yang belum ada. Untuk IPv6 pun mereka punya visi tertentu tentang bagaimana seharusnya digunakan, yang berujung pada keputusan sengaja untuk tidak mendukung fitur seperti stateful DHCPv6.
Opsi DHCP ini tidak umum digunakan, jadi dengan strategi seperti itu, besar kemungkinan opsi ini memang tidak didukung terlepas dari kekhawatiran keamanan.
Jadi ini bukan hal yang terlalu mengejutkan.