TunnelCrack'e karşı TunnelVision: her biri gerçekte neyi kırar

İki araştırma adı, tünelden çıkan her VPN trafiği için birbirinin yerine kullanılıyor, ancak arkalarındaki mekanizmalar aynı değil. TunnelCrack iki yönlendirme istisnası ailesini tanımlar; TunnelVision DHCP'nin uç noktada sağladığı bir rotayı tanımlar. İkisi de şifrelemeyi kırmaz ve ikisi de belirli bir istemci derlemesinin bugün ne yaptığını söylemez. Beş kontrol mekanizmaları başlıktan ayırır.

Birinci adım: incelediğiniz mekanizmayı adlandırın

Ağustos 2023'teki TunnelCrack açıklaması iki saldırı ailesini tanımlar. Yerel ağ durumunda, istemcinin yerel ağa ait saydığı trafik yerel erişim istisnası alır ve tünelden çıkar. Sunucu adresi durumunda, istemcinin VPN sunucusunun kendisine ulaşmak için ihtiyaç duyduğu rota tünelin dışındadır ve bu adresi kontrol eden bir rakip istisnadan yararlanabilir.

TunnelVision, DHCP'nin sağladığı sınıfsız statik rotalar hakkında ayrı bir rapordur. Kötü niyetli bir DHCP sunucusu uç noktaya trafiğin izlediği yolu değiştiren rotalar verebilir; VPN sunucusuna doğru yol da buna dahildir. Rapor, ilgili yönlendirme etkileri üzerine önceki çalışmayı kabul eder; bu da temel mekanizmanın addan daha eski olduğunu hatırlatır.

Adları mekanizmalarına bağlı tutun. Diğeri haberlerde olduğu için birine düzeltme uygulamak, bir incelemenin kapsama olmadan hareket üretme biçimidir.

İkinci adım: yerel erişim istisnasına bakın

Çoğu istemci, tünel açıkken yazıcılar, ekran yansıtma ve dosya paylaşımı çalışmaya devam etsin diye yerel ağ trafiğini muaf tutar. Bu istisna güvenlik maliyeti olan bir politika kararıdır: aynı ağdaki bir rakip kendini yerel ana makine olarak sunabilir ve ona ulaşan trafik tünele hiç girmemiştir.

Dağıtılan profilin bu istisnaya gerçekten ihtiyacı olup olmadığını sorun. Yerel keşfi hiç kullanmayan uzak bir iş gücü bunu çoğu zaman kapatabilir ve kalan yerel hizmetlere belgelenmiş bir yoldan ulaşılabilir. İstisnanın gerekli olduğu yerlerde, onu yerel trafik olarak tanımlamak yerine hangi hedefleri kapsadığını söyleyin.

Kontrol bir yapılandırma sorusudur, paket yakalama değil. Dağıttığınız derleme için profil ayarını ve istemci belgelerini okuyun, çünkü varsayılan değer ürünler arasında ve aynı ürünün sürümleri arasında farklıdır. Yanıtı profilin yanına yazın, böylece bir sonraki gözden geçiren onu davranıştan çıkarmak zorunda kalmasın. Kimsenin belgelemediği bir istisna, kimsenin gözden geçirmediği bir istisnadır.

Üçüncü adım: sunucu adresinin nasıl öğrenildiğine bakın

İstemci herhangi bir tünel var olmadan önce VPN sunucusuna ulaşmak zorundadır, bu yüzden bu hedef tasarım gereği tünelin dışına yönlendirilir. Adres bir addan öğreniliyorsa, çözümleme adımı güven yolunun parçasıdır ve bu sorguyu yanıtlayabilen bir rakip istemciyi kontrol ettiği bir ana makineye yönlendirebilir.

Adresi sabitlemek, doğru adla doğrulanmış bir sertifika kullanmak ve doğrulanmamış bir sunucuya geri düşmeyi reddetmek hepsi maruziyeti azaltır. Hiçbiri sunucuya tünelin dışından ulaşma gereğini ortadan kaldırmaz; o adres için kimin yanıt verebileceğini değiştirirler.

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

Rota sorgusu, istemcinin sunucu adresi için kullanacağı arabirimi gösterir ve bu istisnanın somut biçimidir. Bu sorgu tünel arabirimini döndürürse, istemci tüneli kuramaz bile, dolayısıyla dışarıdan bir rota beklenir ve soru yalnızca hedefinin nasıl seçildiğidir.

Dördüncü adım: DHCP'nin sağladığı rotalara bakın

Sınıfsız statik rotalar bir DHCP sunucusunun yönlendirme tablosu girdileri dağıtmasına izin verir ve uç nokta bunları genellikle sormadan kabul eder. Bir rakibin meşru sunucudan daha hızlı DHCP yanıtlayabildiği bir ağda, bu girdiler kullanıcının tünelin içinde olduğunu sandığı trafiği başka yöne çevirebilir.

Uç noktadaki rotaları beklediğiniz rotalarla karşılaştırın. Tünel açıkken yerel ağ geçidine işaret eden varsayılan bir rota veya geniş bir önek, araştırmaya değer imzadır ve herhangi bir saldırı trafiği olmadan görünür.

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

Son ayar, birçok istemcinin ve platformun bir biçimde sunduğu uç nokta tarafı denetimdir: ağın sağladığı rotaları yok sayın. Otomatik rota kabulünü kapatmak bir ödünleşimdir, çünkü kurumsal bir DHCP sunucusundan gelen meşru bölünmüş yönlendirmeyi de kapatır, bu yüzden bunu küresel olarak değil ağ sınıfına göre kararlaştırın.

Beşinci adım: bildirimi güncel derlemeden ayırın

Yayımlanmış bir saldırı, belirli istemci sürümlerinde belirli bir zamanda gözlenen davranışı tanımlar. Önünüzdeki dizüstü bilgisayarın etkilendiğini kanıtlamaz ve düzeltildiğini de kanıtlamaz. Her iki iddia da gerçek derleme numarasını ve satıcının güncel bildirimini gerektirir.

İstemci sürümünü, platformu, yukarıdaki istisnaları yöneten profil ayarlarını ve kontrol ettiğiniz tarihi kaydedin. Bu kayıt dürüstçe eskir, oysa VPN'in TunnelCrack için yamalandığını söyleyen bir not dürüstçe eskimez. İstemci her güncellendiğinde yeniden okuyun, çünkü bir profil varsayılanı dokunmadığınız bir sürüm altında değişebilir.

Gerçekten doğrularken, onaylanmış bir planı kendi uç noktanıza ve zararsız bir hedefe karşı kullanın. Paylaşılan bir ağda diğer kullanıcılara karşı saldırıyı yeniden üretmek bir test değildir ve gözlemi kolaylaştırmak için eş doğrulamayı veya uygulama şifrelemesini kapatmak ölçmeye çalıştığınız korumayı ortadan kaldırır.

Son olarak, uygulama düzeyindeki korumayı resimde tutun. Bir yönlendirme istisnası tünelin taşıyacağı trafiği açığa çıkarabilir ve uygulamanın TLS'i bu trafiği uçtan uca korumaya devam eder. İki katman bağımsız olarak başarısız olur, bu yüzden bağlı bir denetim kanalı her akışın amaçlanan yolu izlediğinin kanıtı değildir.