Mullvad exit IP’leri şaşırtıcı derecede ayırt edilebilir

 (tmctmt.com)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Mullvad bir sunucuda birden fazla exit IP bulunduruyor, ancak bunları WireGuard anahtarına göre deterministik biçimde atıyor; her bağlantıda rastgele değişmiyor
  • 9 sunucuda pubkey’i tekrar tekrar değiştirerek toplanan 3.650 veri noktası, teoride mümkün olan 8,2 trilyon kombinasyon içinden yalnızca 284 kombinasyona atandı
  • Her sunucunun exit IP’si havuz içinde benzer bir yüzdelik konumda yer alıyor; tek bir kombinasyon birçok sunucuda kabaca 81. yüzdeliğe denk geliyor
  • Bunun nedeni, pubkey veya tünel adresini seed olarak kullanıp havuz boyutunu üst sınır yapan seed tabanlı RNG ile exit IP indeksinin seçilmesi gibi görünüyor
  • IP loglarındaki float aralıkları çakışırsa, farklı Mullvad sunucuları kullanılsa bile hesaplar arasında ilişki kurulabiliyor ve anonimlik riski büyüyor

Mullvad exit IP’lerinin bir fingerprinting vektörüne dönüşme yapısı

  • Mullvad bir sunucuda birden fazla exit IP sunuyor ve aynı sunucuya bağlanan iki kullanıcıya genelde farklı genel IP’ler veriliyor
  • Sunucu sayısı 578; bu sayı Proton VPN’in 20.000 sunucusundan daha az. Bu nedenle kullanıcıları tek bir IP’de yoğunlaştırmayan dikey ölçekleme, aşırı IP engelleme ve hız sınırlamasından kaçınmak açısından avantaj sağlayabiliyor
  • Ancak sunucuya her bağlanışta exit IP rastgele değişmiyor; WireGuard anahtarına göre deterministik olarak seçiliyor
  • WireGuard anahtarı 1 ila 30 günde bir döndürülüyor, ancak üçüncü taraf istemcilerde döndürülmüyor
  • Her sunucuda bağımsız şekilde sabit bir exit IP atanıyorsa, yalnızca birkaç sunucudaki IP kombinasyonu bile bir kullanıcıyı diğer Mullvad kullanıcılarından ayırmaya yetebilir

9 sunucuda gözlemlenen exit IP kombinasyonları

  • pubkey’i tekrar tekrar değiştirerek 9 sunucunun exit IP’lerini toplayan bir betik gece boyunca çalıştırıldı ve 3.650 pubkey veri noktası elde edildi
  • Bu sunuculardaki exit IP aralıkları şöyle gözlemlendi
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
  • Bu sunucuların havuz boyutları çarpıldığında, teoride 8,2 trilyondan fazla exit IP kombinasyonu mümkün görünüyor
  • Gerçekte test edilen tüm pubkey’ler bunların içinden yalnızca 284 kombinasyondan birine atandı
  • Olası kombinasyon sayısına kıyasla gözlemlenen kombinasyon sayısının çok az olması, sunucu başına IP seçiminin bağımsız olmadığına işaret ediyor

Farklı IP’lerin aynı yüzdelikte yer alma deseni

  • Exit IP’nin havuz başlangıç IP’sinden ne kadar uzakta olduğuna bakılarak sayısal konum hesaplanabiliyor
  • Örneğin au-syd-wg-101 üzerinde 103.136.147.53, 103.136.147.5 adresinden sayıldığında 1-based indeks olarak 49’a denk geliyor
  • Gözlemlenen kombinasyonlardaki IP konumu, her sunucunun havuz boyutuna bölündüğünde farklı sunucularda bile neredeyse aynı oran ortaya çıkıyor
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
  • Her IP, kendi havuzunda benzer bir yüzdelik konuma düşüyor; yukarıdaki örnek genel olarak 81. yüzdeliğe karşılık geliyor
  • Bu desen nedeniyle Mullvad’ın tüm sunucularda birbirine komşu konumlardaki exit IP’leri atıyormuş gibi göründüğü belirtiliyor

Muhtemel neden: seed tabanlı rastgele seçim

  • cl-scl-wg-001 ile za-jnb-wg-002, gözlemlenen 284 IP kombinasyonunun tamamında her zaman aynı IP indeksini paylaşıyor
  • Bu iki sunucunun ortak noktası 11’lik havuz boyutu ve bu durum, aynı seed ile aynı sınırlar kullanıldığında aynı sonucu veren rastgele çağrı yapısıyla uyumlu
  • RNG statik bir seed ile başlatılıp aynı aralıkta sayı çekildiğinde aynı sonuç tekrar ediyor
  • Mullvad’ın pubkey veya tünel adresini seed olarak kullanıp havuz boyutunu üst sınır olarak veren seed tabanlı RNG ile exit IP indeksini seçtiği düşünülüyor
  • Bounds değişse bile RNG’nin entropi havuzu etkilenmiyor; Rust tarafında ilk çağrıda aynı float’ın üretilip bounds ile çarpılması gözlemlerle örtüşüyor
  • Bu davranış min + round((max - min) * float) gibi basitleştirilerek düşünülebilir, ancak bu ifade önemli ölçüde sadeleştirilmiş olabilir
  • Bu özellik yüzünden havuz boyutları farklı olsa bile aynı seed’den çıkan float, her sunucu havuzunda benzer oransal noktaya eşleniyor
  • Mullvad istemcisi Rust ile yazıldığı için backend dilinin de Rust olabileceği belirtiliyor, ancak bu yalnızca istemci uygulamasına bakılarak yapılan bir çıkarım
  • random_range’in bounds değişimine göre tam olarak nasıl davrandığını öngörmek zor; bounds artışının entropiyle karışıp farklı sayılar üreteceğini düşünmek kolay, ancak gerçek gözlemler bunu göstermiyor

IP log korelasyonundan doğan anonimlik riski

  • Belirli bir IP kombinasyonu için mümkün float değerlerinin minimum ve maksimumunu tahmin eden bir araç mullvad-seed-estimator olarak sunuluyor
  • Ekran görüntüsündeki belirli IP kümesi 0.2909~0.2943 aralığındaki float değerleri olarak yorumlanıyor; fark 0.0034
  • Bu da Mullvad kullanıcılarının %0,34’ünün bu IP’leri paylaştığı anlamına geliyor; kabaca 100.000 aktif kullanıcı varsayımında bu sayı 340 kişiye denk geliyor
  • İlk tahmin edildiği kadar benzersiz olmasa da %99’dan yüksek doğruluk yine de düşük sayılmaz
  • Örneğin bir forum yöneticisi, bir gün önce engellediği kullanıcının sockpuppet’i olduğundan şüphelendiği yeni bir hesabı incelerken, iki hesap farklı Mullvad sunucuları kullanmış olsa bile IP logları 0.4334 - 0.4428 ve 0.4358 - 0.4423 gibi çakışan float aralıkları içeriyorsa aynı kişi olma olasılığı %99’un üzerine çıkıyor
  • Veri sızıntısı veya hukuki süreçlerle elde edilen IP loglarına da aynı korelasyon uygulanırsa, VPN arkasındaki kullanıcı anonimliği zedelenebilir

Korunma yöntemi

  • Her pubkey için sunucuyu bir kereden fazla değiştirmemek öneriliyor
  • Mullvad uygulamasında oturumu kapatarak pubkey’i zorla döndürmek mümkün

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News görüşleri

  • Mullvad’da çalışan ortak CEO ve kurucu ortak benim. Yazıda bahsedilen davranışların bir kısmı kasıtlı, bir kısmı değil; sebep de blog yazısındaki açıklamayla tam olarak aynı değil
    Hafifletme olarak, kasıtsız davranışa yönelik bir yamayı altyapının bir kısmında zaten test ediyoruz; bu yüzden bugün yeniden üretmeyi denerseniz sonuçlar kafa karıştırıcı olabilir
    Kasıtlı davranışın da kabul edilebilir olup olmadığını yeniden değerlendireceğiz; burada çeşitli gizlilik unsurları ile kullanıcı deneyimi arasında bir denge var
    Bu değerlendirme, bunu bir saat önce öğrendikten sonra operasyon ekibiyle hemen konuşup bu yorumu yazarken toparladığım mevcut görüşüm; değişebilir
    Güvenlik araştırması yapanların, güvenlik·gizlilik sorunu bulduklarında hemen yayımlamayı planlasalar bile önce yöneticiye ya da satıcıya haber vermelerini isterim

    • Mullvad istemcisinde varsayılan anahtar döndürme aralığı muhtemelen 72 saat ve CLI istemcisi de biraz düzenlemeyle yerel WireGuard kullanan çoğu durumda çalıştırılabilir
      mullvad tunnel get ile kontrol edebilir ve mullvad tunnel set rotation-interval ile değiştirebilirsiniz; yazıda tercih edilen hafifletme yöntemi de bu
      Şahsen yarı sabit IP’yi büyük bir sorun olarak görmüyorum. Amaç ISP ve devletin ağ düzeyindeki gözetimini engellemek; hatta bazı sağlayıcılar sabit IPv4’ü özellik olarak satıyor
      Gizlilik odaklı VPN’lerde, IP alanı ne kadar küçükse dışarıdan görülen tek bir IP’nin arkasında o kadar çok kullanıcı karışabilir; bunun da avantajı var. DAITA gibi tünele sahte trafik ekleyen tekniklerle çoklu atlamalı giriş noktalarını birleştirince, gün boyu netflow izleyen gözetmenler için işi gerçekten zorlaştırabileceğini düşünüyorum
    • Obscura CEO’su ve Mullvad ortaklarından biri olan Carl benim. İlginç bir bulgu ama kfreds’in dediği gibi, yayımlamadan önce satıcıya haber verilmesi daha iyi olurdu
      Temel bulgu olan sunucular arası IP havuzu içi konum korelasyonu, gerçekten de kasıtsız davranış içeriyor gibi görünüyor. Mullvad ekibiyle çalışma deneyimime dayanarak bunun yakında ele alınacağını düşünüyorum
      Farklı “kimlikler” istiyorsanız WireGuard anahtarını döndürmeniz ya da farklı anahtarlar kullanmanız gerekir
      Yazıda, “bir sunucuya her bağlandığınızda çıkış IP’si rastgele değil, WireGuard anahtarına göre deterministik olarak seçiliyor ve bu anahtar 1-30 günde bir döndürülüyor. Üçüncü taraf istemci kullanırsanız döndürülmüyor” denmişti; ancak WireGuard tasarım gereği bağlantısız bir protokoldür, yani bağlantı kavramı yoktur; yalnızca trafik aktığında 2-3 dakikada bir yeniden anahtarlama el sıkışması olur
      Aynı WireGuard anahtarıyla bile her “bağlantıda” — örneğin her yeniden anahtarlama el sıkışmasında ya da her 15 dakikada bir — çıkış IP’si değişseydi, aktarım katmanında QUIC hariç tünel içindeki neredeyse tüm bağlantılar kopup yeniden kurulmak zorunda kalırdı; uygulama katmanında ise “aynı çerez, yeni IP”den şüphelenen servisler çıkış yaptırır, CAPTCHA gösterir ya da risk puanı üretirdi
      Bunların ikisi de kötü kullanıcı deneyimi yaratır; daha kötüsü, “bu kişi sürekli farklı IP’lerden yeniden bağlanıyor, demek ki Mullvad kullanıcısı” gibi kullanıcıyı daha ayırt edici biçimde parmak iziylemeye yol açabilir

  • “Bir forum yöneticisi, önceki gün engellediği kullanıcının yan hesabı olup olmadığından şüphelenip IP loglarına baktığında, farklı Mullvad sunucuları kullanmalarına rağmen iki hesabın çakışan kayan nokta aralıkları 0.4334~0.4428 ve 0.4358~0.4423’e eşlendiğini, dolayısıyla %99’dan yüksek olasılıkla aynı kişi sayılabileceklerini” söyleyen örnek, bir istihbarat teşkilatı VPN tasarlasa herhalde böyle yapardı hissi veriyor

    • Neden öyle olsun bilmiyorum. Bir istihbarat teşkilatı VPN tasarlasa, çıkış düğümü istatistiklerine bel bağlamak yerine VPN’e bağlanan tüm IP’leri loglardı
      Üstelik bu yöntem, kullanıcıların farklı sunucular seçmesine bağlı; bu yüzden daha da anlamsız olurdu
    • Günün birinde Cloudflare’ın da istihbarat servisleriyle bağlantılı olduğu ortaya çıkacakmış gibi geliyor. “Ani DDoS”un çözümü sitenizi Cloudflare’ın arkasına koymaksa, o ani saldırıları kimin yapabildiğini de merak ettiriyor
    • Yine de log tutmama gibi küçük bir ayrıntı hâlâ var
      Bana göre bu büyük bir sorun ve birden çok VPN çıkış düğümü arasında korelasyon analizi yapılmasını mümkün kılıyor, ama hepsi bu. Kullanıcıyı otomatik olarak teşhis etmeyi sağlamıyor
      Yine de teşhis zorluğunu ciddi biçimde düşürüyor ve gereksinimler hâlâ yüksek. Umarım yakında düzeltilir
      “Hash gibi hassas bir değerden üretelim” türü bir hatanın, hem de Mullvad’da, hâlâ yaşanmasına inanmak zor. Neden sadece rastgeleleştirilmedi acaba diye düşünüyorum
    • Mullvad, Snowden ifşalarından yıllar önce vardı ve o belgelerin hiçbirinde geçmiyordu
      Elbette başka istihbarat teşkilatları da var ama en çok endişe edilmesi gereken taraf orası. Ya doğrudan işletmişlerdir ya da böyle bir fikri bilip uygulamışlardır ya da ortak kurumların işlettiği servislere erişimleri vardır. Aksi hâlde benim için tehdit olmazdı
      Ayrıca Mullvad kullanıcılarının VPN üzerinden anonimliklerinin bozulduğu bilinen kamuya açık bir vaka yok; bilinenler daha çok başka operasyonel güvenlik hataları yüzünden ortaya çıkan vakalar. Eğer istihbarat servislerinde bu yetenek olsaydı, neredeyse 20 yıllık veriye sahip olup hiç kullanmamış olmaları pek inandırıcı gelmiyor
    • İstihbarat teşkilatı bir VPN’i kontrol ediyorsa trafiği doğrudan izler. Dış gözlemcilerin hangi kullanıcının hangi çıkış IP’sinden çıktığını tahmin etmesini kolaylaştırmak için bir teşviki olmaz

  • Yazıdaki sayılardan yalnızca “%99’dan yüksek olasılık” sonucunun nasıl çıktığını anlamıyorum. İlk engellenen IP’nin tohumu ile ikinci tohumun ikisinin de 0.4423~0.4358 aralığında olduğunu güçlü biçimde varsaysak bile, bu yalnızca bu aralığın tüm Mullvad kullanıcılarının %0,65’ini kapsadığı anlamına gelir
    100 bin kullanıcı varsa bu 650 kişi eder; yani “şüphelileri” %99’dan fazla azaltmış olursunuz ama birden çok çıkış IP’si üzerinde tek bir kişiyi %99’dan yüksek doğrulukla tespit etmiş olmazsınız
    Bayesçi açıdan bakarsak, olası tohumların çakışması iki IP’nin aynı kişiye, en azından aynı Mullvad hesabına ait olduğuna dair güçlü kanıt olur; ama yazının iddiası bu gibi görünmüyor

    • Forum epey büyükse, örneğin 1000 aktif kullanıcısı varsa ve her gün 1 kişi kayıt oluyorsa, biri engellendikten sonraki gün bu VPN’i kullanan birinin kaydolup benzer aralıkta IP’ye sahip olma olasılığı ne olur diye düşünmek gerekir
      Çoğu küçük web sitesi için bu oldukça güçlü bir kanıt olur

  • VPN’in amacı, ziyaret edilen sitelere karşı kullanıcıyı anonimleştirmeyi kapsamaz; bu yüzden Mullvad’ın benzersiz çıkış IP’lerini zorlamaması şaşırtıcı değil. Anonimlik isteyen kullanıcılar Tor gibi bir ağ kullanmalı

    • Neden olmasın anlamıyorum. Belirli bir VPN hizmetinin amacının bu olamaması için bir neden yok
    • Tor bir ABD hükümeti projesi ve anonimliği bozmanın mümkün olduğu gösterilmedi mi?
    • Bu tam olarak genel VPN’in amacı
      Genel VPN kullanıyorsanız isteği kimin gönderdiğini, uç IP dâhil, kimsenin bilmemesini istersiniz
      O mantıkla VPN torrent için kullanılmamalı. Çünkü uç IP’ye karşı anonimleştirmemesi gerektiği anlamına gelir. Oysa pratikte torrentte gayet iyi çalışıyor
      Özel VPN’den bahsediyorsanız Mullvad öyle bir şey değil

  • Uzun süredir Mullvad kullanıyorum ve ülkemde yasal olduğu sürece, adıma kayıtlı kredi kartımla Mullvad VPN hizmetini satın almaya ve kullanmaya devam edeceğim
    VPN %100 anonimlik sağlamaz ve zaten bunun için tasarlanmamıştır. Bunun yerine, yasaya uyan yetişkinlere belli ölçüde gizlilik sağlamak içindir
    Çoğu insan, iş arkadaşlarının ve komşularının özel yaşamını, neleri sevdiğini, neler satın aldığını, neler yaptığını bilmesinden utanır. Bu yüzden çoğu insan gizliliğini korumak için VPN kullanmalıdır
    Tanım gereği “çoğu insan” internette %100 anonimlik istemez ya da bunu beklemez; sadece kişisel yaşamında ve ilişkilerinde biraz gizlilik ister
    VPN, çevrimiçi suç işleyip devletten %100 anonim kalmak isteyen suçluları korumaz; amacı da bu değildir. Bu ayrım önemlidir. “Çoğu insan” suçlu değildir ve Mullvad’dan ya da başka VPN sağlayıcılarından böyle gerçek dışı beklentiler içinde değildir

    • VPN anonim değildir; insanlar sadece öyleymiş gibi davranır. Yine de bu raporun bulgusu, kullanıcı tanımlamayı beklenenden daha kolaylaştıran bir unsur gösteriyor
      Sırf yukarıdaki mantık yüzünden raporu çöpe atamayız. Bulgunun kendisi hâlâ geçerli

  • Eksik kalan bir şey var. Mullvad ile iletişime geçilip geçilmediğini merak ediyorum. Güvenlik ekibinin nasıl yanıt verdiğini görmek de ilginç olurdu

    • Bildiğim kadarıyla iletişime geçilmedi; bunu hem operasyon hem de destek ekibine sordum. Yanılıyorsam bu yorumu güncellerim
      Sonradan fark ettim ki bu yorumu yazdığıma pişman oldum. Gereksizdi ama şimdi silersem garip görünebilir
    • Hayır ama bu gönderide en üstte oylanan yorum Mullvad kurucu ortağının yanıtı

  • İnsanların VPN’den Tor’a benzer bir şey beklemesi bana şaşırtıcı geliyor
    Böyle açınca kulağa mantıksız geliyor ve çıkış düğümlerini kontrol ederseniz Tor kullanıcılarının bile anonimliğini bozmanın mümkün olabileceğini de hesaba katmak gerekir

    • Büyük tüketici odaklı VPN’lerin çoğu pazarlamada “gizlilik”i anonimlik gibi ima ediyor; o yüzden şaşırtıcı değil
    • Tor’un tasarımının bir parçası, birden çok röle düğümünden geçmek değil miydi; dolayısıyla çıkış düğümü de kaynak IP’yi göremiyor olmalı, değil mi?
    • Beklenen şey bu olmayabilir ama mümkünse gizlilik sağlamak için yapabileceklerini yapmaya çalışacaklarını düşünür insan

  • “Çıkış IP’si her bağlandığınızda rastgeleleştirilmiyor, WireGuard anahtarına göre deterministik seçiliyor ve bu anahtar 1-30 günde bir döndürülüyor. Üçüncü taraf istemci kullanırsanız hiç döndürülmüyor” kısmı biraz kafa karıştırıcı
    Yöntem depoda ayrıntılı anlatılıyorsa, üçüncü tarafın varsayılan uygulama istemcisi gibi anahtar döndürme yapmasını engelleyen şeyin ne olduğunu anlamıyorum

    • Üçüncü taraf istemcilere, örneğin Linux çekirdeğindeki WireGuard sürücüsü de dâhil. Bir ağ sürücüsünün, belirli bir ticari hizmete yönelik bir saldırıyı hafifletme sorumluluğunu üstlenmesi beklenemez
    • Esasen engelleyen şey, bunun yapılması gerektiğini bilmek

  • Yazar iyi yakalamış ve bunun Mullvad’ın bir hatası olması da gayet inandırıcı. Böyle basit bir şeyin gözden kaçmış olması oldukça sarsıcı ama ben de kaçırabilirdim gibi geliyor
    Birden çok sunucu arasındaki IP korelasyonu dışında, başta neden tek bir sunucuda kullanıcı IP’sini kararlı tuttuklarını da merak etmiştim. Ama yazarın, diğer VPN’lerin genelde sunucu başına tek IP kullandığını ve bunun taklit edildiğini söyleyen açıklaması mantıklı
    Kullanıcı belirli bir hizmete erişebildiği bir sunucu bulursa, yeniden o sunucuya bağlandığında aynı IP’yi alıp tekrar çalıştırabilmesinin bir avantajı var
    Yine de sunucular arası IP korelasyonu rand.seed(user_pub_key + server_id) gibi bir şeyle düzeltilmeli

    • Tersine, aynı IP’deki gürültülü komşular yüzünden bir hizmette engellendiyseniz, kullanıcının bunu aşmasının bir yolu yok mu?

  • IPinfo’da çalışıyorum. VPN tespiti işimiz var ama dürüst olmak gerekirse Mullvad’a iyi niyet atfetmek istiyorum
    Mullvad, bizim gibi IP coğrafi konum sağlayıcılarına bilerek yanlış coğrafi konum verisi göndermeye çalışmayan üç VPN sağlayıcısından biriydi. Bunu da düzelteceklerinden eminim

    • Diğerleri kimdi?