Başarısız bir VPN el sıkışması gerçekten bir downgrade saldırısı mı?

Hatayla biten bir el sıkışma, mesaja bakana kadar saldırı gibi hissettirir ve çoğu zaman mesele aritmetiktir: ortak bir teklif yok, süresi dolmuş bir sertifika ya da hiç ulaşmayan bir paket. Downgrade saldırısı belirli bir şeydir: saldırganın iki ucu seçeceklerinden daha zayıf davranışa itmesi ve farklı kanıtlar bırakması. Her başarısızlığı kötü niyet saymak sizi var olmayabilecek bir kurban aramaya gönderir, gerçek bir downgrade'i yapılandırma hatası saymak ise zayıf sonucu yerinde bırakır. İki hatanın maliyeti farklıdır ve yalnızca biri ucuz düzeltilir.

Downgrade saldırısı gerçekte neyi değiştirir

Amaç şifreyi kırmak ya da anahtarı tahmin etmek değildir. Amaç, her iki tarafın saldırganın başa çıkabileceği daha eski bir sürümde veya daha zayıf bir algoritmada durmasını sağlamak ya da bir tarafı diğerinin yalnızca bunu desteklediğine inandırmaktır.

Değişen şey anlaşmadır, kimlik doğrulama değil. Saldırgan teklifi fark edilmeden değiştirebiliyorsa, taraflar yine de el sıkışmayı tamamlayabilir ve birbirlerini doğrulayabilir, ancak saldırganın tercih ettiği parametrelerle. Bu yüzden ilginç soru, müzakerenin kendisinin bütünlük koruması kapsamında olup olmadığıdır.

Müzakerenin kendisi neden doğrulanmalı

TLS 1.3 bu korumayı açık hale getirir. Daha yeni sürümü öneren bir istemci sessizce geri düşen bir sunucuyu tespit edebilir, çünkü sunucunun rastgele değeri 1.2 veya altını müzakere ederken sabit bir desen taşır ve istemci bunu görünce durmak zorundadır. Tüm transkript de bitiş mesajlarıyla kapsanır, bu yüzden müzakerede herhangi bir yerdeki değişiklik sessizce geçmek yerine sonradan başarısız olur.

Daha eski protokol sürümlerinin hikâyeleri daha zayıftı ve geri dönüş kurallarının önemi tam olarak bu yüzdendir. Aynı yapılandırmadaki bir TLS 1.0 uç noktası downgrade saldırısı değildir; izin vermeyi sizin seçtiğiniz izinli bir sonuçtur. Ayrım, zayıf sonucun korumalı bir karardan mı yoksa bir aracının etkileyebileceği korumasız bir yoldan mı geldiğidir. Bunu böyle ifade ettiğinizde olayların çoğu bir yapılandırma sorusuna indirgenir.

IKEv2 farklı davranır ama aynı fikre dayanır. Teklif, iki tarafı da sonradan doğrulayan bir değiş tokuşta taşınır, bu yüzden algoritmaları yeniden yazan bir ara kutu kimlik doğrulamayı yönlendirmek yerine kırar. OpenVPN'in kontrol kanalı müzakereyi TLS ile korur ve sonra bu kanalı veri kanalının şifrelerini kararlaştırmak için kullanır, bu yüzden ilginç olan kontrol kanalı günlük satırıdır.

Yapılandırılmış uyumluluk bir saldırı değildir

Bir yönetici belgelenmiş bir istemciyi desteklemek için eski seçeneklere bilerek izin verebilir ve bu karar yapılandırmada görünür. Saldırgan bu yapılandırmayı oluşturamaz; yalnızca teklifi etkilemesine izin veren bir yolu kullanabilir.

Tehlikeli onarım farkın kanıtını ortadan kaldırandır. Her eski seçeneği etkinleştirmek, sertifika doğrulamasını kapatmak ya da hata kaybolsun diye herhangi bir şifreyi kabul etmek uç noktanın kabul edeceği şeyi genişletir ve zayıf sonucu bildirecek denetimleri ortadan kaldırır.

Bir eski seçeneği tutmanız gerekiyorsa yapılandırma yorumunda nedeni ve istemciyi belirtin, sonra seçeneği ona ihtiyaç duyan profille sınırlayın. Tek bir dinleyiciyle sınırlı bir uyumluluk istisnası denetlenebilir; genel olarak uygulanan ise kimsenin seçtiğini hatırlamadığı daha zayıf bir varsayılandır.

Nedeni adlandırmadan önce başarısızlığı okuyun

Herhangi bir değişiklikten önce tam hata dizesini, istemci ve sunucu sürümlerini ve zamanı saklayın. Sonra sınıflandırın: taraflar bir teklifte anlaşamadı mı, paket yolu mu başarısız oldu, yoksa bir taraf bir zamanlar kabul ettiği bir parametreyi mi reddetti?

Teklif uyuşmazlığı genellikle sorunlu sürümleri ya da algoritmaları adlandırır ve her seferinde aynı noktada başarısız olur. Yönlendirme veya MTU sorunu durur ya da zaman aşımına uğrar ve genellikle ağa göre değişir. Süresi dolmuş bir sertifika müzakere değil doğrulama hatası verir.

Bunların hiçbiri saldırganın kanıtı değildir. İlk başarısızlıkta kötü niyetli neden atamak hatadır, çünkü yarın yine başarısız olacak deterministik hatayı gizler.

Gerçekte ne seçildiğini doğrulayın

Herhangi bir düzeltmeden sonra bağlantının kalktığına güvenmek yerine müzakere edilen sonucu okuyun. Doğrulama kaldırıldığı için başarılı olan bağlantı, kaçınmaya çalıştığınız sonucun ta kendisidir. Aşağıdaki iki komut, TLS önündeki bir uç nokta için seçilen sürümü ve şifreyi, ayrıca bir OpenVPN sunucu günlüğünden kontrol kanalı satırını gösterir.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

Sonucu şu anda bağlananla değil, amaçladığınız yapılandırmayla karşılaştırın. Seçilen sürüm izin verilen minimumdan eskiyse profil ya da geri dönüş listesi bakılacak yerdir ve cevap o listeyi düzeltmektir, saldırı ilan edip etrafındaki her şeyi yeniden kurmak değil.