- British Airways'in uçak içi ücretsiz mesajlaşma WiFi hizmetinin, aslında belirli alan adlarına dayalı filtreleme üzerinden sınırlı internet erişimine izin verdiği ortaya çıktı
- Yazar, TLS SNI(Server Name Indication) alanını değiştirerek havayolu sistemini trafiği mesajlaşma trafiği sanması için kandırdı ve normal web sitelerine erişmeyi başardı
- Bunun için SNI olarak
wa.me (WhatsApp alan adı) ayarlandı ve trafik HTTPS proxy ile stunnel kullanılarak yönlendirildi
- Deney sonucunda metin ağırlıklı siteler (Hacker News gibi) normal şekilde yüklenirken, görseller veya büyük içerikler bant genişliği sınırlaması nedeniyle yavaş aktarıldı
- Bu vaka, TLS SNI tabanlı filtrelemenin zayıflığını ve bunu tamamlamak için ECH(Encrypted Client Hello) teknolojisine duyulan ihtiyacı gösteriyor
Ücretsiz mesajlaşma WiFi'ı nasıl çalışıyor
- British Airways, “The British Airways Club” üyelerine yalnızca mesajlaşma için ücretsiz WiFi sunuyor
- Kayıt, uçak içi portalda e-posta doğrulaması olmadan yapılabiliyor; WhatsApp, Signal ve WeChat çalışırken Discord engellendi
- Yazar, bu hizmetin yalnızca mesajlaşma uygulamalarına nasıl izin verdiğini merak etti
- Basit bir trafik kısıtlaması değil, TLS SNI alanı tabanlı bir alan adı beyaz listesi olduğu sonucuna vardı
- Wireshark analizi,
example.com bağlantısında Client Hello sonrasında TCP reset yaşandığını gösterdi
- Bu, TLS el sıkışması sırasında açığa çıkan SNI değeri kullanılarak izin verilmeyen alan adlarının engellendiği anlamına geliyor
SNI tabanlı filtrelemenin mantığı
- TLS SNI, şifreleme öncesi aşamada bağlanılmak istenen alan adını düz metin olarak gönderir
- Bu sayede ISP'ler veya ağ yöneticileri, kullanıcının hangi siteye bağlandığını görebilir
- British Airways, yalnızca mesajlaşma uygulamalarıyla ilgili alan adlarını beyaz listeye aldı ve diğer bağlantıları resetledi
- Yazar, SNI olmadan doğrudan IP bağlantılarının da (
openssl s_client -connect) engellendiğini doğruladı
- Yani SNI'nin eksik olması da başlı başına anormal trafik olarak değerlendiriliyordu
SNI değiştirme deneyi
- Yazar, SNI olarak
wa.me (WhatsApp alan adı) ayarlayarak TLS bağlantısı kurmayı denedi
- Sunucu sertifikası
wa.me için değildi, ancak istemci sertifika uyumsuzluğunu görmezden gelirse bağlantı kurulabiliyordu
- Sonuç olarak BA sistemi bunu mesajlaşma trafiği sanarak TLS tüneline izin verdi
- Ardından HTTP istekleri doğrudan yazılarak kendi sunucusundaki (
saxrag.com) içerik başarıyla alındı
- Bu deney, yalnızca SNI alanını kandırarak keyfi trafik taşınabildiğini kanıtladı
HTTPS proxy ile tam atlatma
- Yazar,
tinyproxy ve stunnel kullanarak bir HTTPS proxy sunucusu kurdu
stunnel, TLS katmanı ekleyerek istemcinin wa.me bağlantısı kuruyormuş gibi görünmesini sağladı
curl komutunda --resolve seçeneği kullanılarak wa.me, kendi VPS IP'sine eşlendi
- Böylece SNI
wa.me olarak ayarlanırken gerçek bağlantı kişisel sunucuya yapıldı
- TLS sertifika hataları
--proxy-insecure ile yok sayıldı ve proxy üzerinden dış isteğin başarılı olduğu görüldü
ifconfig.co isteğinde VPS IP'si döndü ve proxy'nin çalıştığı doğrulandı
Gerçek uçuş sırasında test
- Dönüş uçuşunda aynı ayarla WiFi'a bağlanıldı ve
curl üzerinden normal bir HTTP 200 yanıtı alındı
- Ardından tarayıcıda (Chromium) HTTPS proxy ayarlandı ve
wa.me, hosts dosyasına eklendi
- Sonuçta Hacker News sitesine erişim başarılı oldu ve metin tabanlı sayfalar düzgün yüklendi
- Wireshark'ta
SSLKEYLOGFILE kullanılarak TLS trafiğinin çözüldüğü de doğrulandı
- Görseller ve büyük içerikler satır satır yavaş yüklendi; bunun bant genişliği sınırlamasından kaynaklandığı tahmin edildi
- Bu da BA'in SNI'ye ek olarak trafik hız sınırlandırması uyguladığını düşündürüyor
ECH(Encrypted Client Hello) deneyi
- Yazar, TLS SNI sızıntısı sorununu çözen ECH teknolojisini doğrudan test etti
wa.me, public_name olarak ayarlanmış bir ECHConfig oluşturuldu ve Firefox'ta uygulandı
- Sonuçta dış SNI
wa.me olarak kalırken iç ClientHello gerçek alan adını (rfc5746.mywaifu.best) içerdi
- Let’s Encrypt sertifikasıyla normal bir TLS bağlantısı kuruldu
- İlginç biçimde bu yöntem standart dışı 7443 portunda da çalıştı ve British Airways filtrelemesini atlattı
- Yazar, ECHConfig'in DNS-over-HTTPS(DoH) üzerinden iletilmiş olabileceğini öne sürdü
SNI'nin sınırları ve güvenlik çıkarımları
- SNI, aslında sunucu sertifikası seçimi için kullanılan bir “ipucu” düzeyinde bilgi
- İstemci ve sunucunun her ikisinin de kontrol edilebildiği ortamlarda istenen herhangi bir SNI değeri eklenebilir
- Bu, sansür sistemleri veya tehdit tespit çözümlerinin SNI tabanlı filtrelemeye aşırı bağımlı olması halinde yanlış tespit riski taşıdığı anlamına geliyor
- Kötü amaçlı yazılım geliştiricileri, C&C sunucularına bağlanırken zararsız alan adı gibi görünen SNI kullanabilir
- Bu nedenle ağ güvenliği politikalarının SNI dışında ek trafik analizi ve şifreleme katmanı doğrulaması da içermesi gerekiyor
Sonuç
- British Airways'in ücretsiz WiFi'ı, SNI tabanlı alan adı filtrelemesi ve bant genişliği sınırlamasıyla yalnızca mesajlaşma trafiğine izin veriyor
- Ancak deneyler, SNI değiştirilerek keyfi HTTPS trafiğinin mesajlaşma gibi gösterilebildiğini kanıtladı
- Bu vaka, TLS tasarımındaki yapısal sınırları ortaya koyuyor ve ECH kullanımının gerekliliğini vurguluyor
- Ağ işletmecileri ve güvenlik ekiplerinin SNI'ye bağımlı filtrelemenin zayıflıklarını fark etmesi gerekiyor
- Teknik açıdan ilginç bir atlatma örneği olsa da, bu çalışma güvenlik ve etik değerlendirmelerle birlikte ele alınmalı
1 yorum
Hacker News yorumu
Bazı havayolları (muhtemelen American Airlines) Fortinet güvenlik duvarı kullanıyor; yani sadece SNI’a bakmıyor, sunucu sertifikasının ana makine adını ve sertifika otoritesini de doğruluyor
Arkadaşım bunu, aa.com’un SNI’ını kullanıp gerçek aa.com TLS 1.2 el sıkışmasını aynen ileterek aşmış
Sonrasında şifreli veri aşamasında bu el sıkışmasını yok sayıp hattı sadece şifreli bir tünel olarak kullanmış
Günümüzde TLS 1.3 kullanılırsa sertifika şifreli olduğu için güvenlik duvarı içeriği göremez; böylece bu tür sorunlardan kaçınılabilir
Belirli bir SNI’a uyan istek gizli anahtar olmadan gelirse tüm SSL el sıkışmasını kamuflaj amaçlı web sitesine proxy’liyor
Aksi halde SSL trafiği gibi görünen normal bir proxy olarak çalışıyor
Aslen Çin’in GFW’sini (Büyük Güvenlik Duvarı) aşmak için yapılmıştı ama arkadaşım SNI olarak Google Analytics ayarlayınca American’ın uçak içi güvenlik duvarında da çalıştığını söyledi
Wi-Fi ve uygulama ücretsiz çalışıyor ama trafiğin çoğu engelleniyor
Wireshark’ta gördüğüm kadarıyla TCP bağlantısının başında birkaç pakete izin veriyorlar, ardından ClientHello’yu inceleyip yalnızca beyaz listedeki alan adlarını geçiriyorlar
Cruise uygulaması, şirket alan adı beyaz listede olduğu için çalışıyor
Bu tür açıkları suistimal etmemek ve sessizce kullanmak lazım. Fazla yayılırsa kapatırlar; yazık olur
Anten ve abonelik pahalı olsa da, cruise şirketlerine karşı bir tür ‘özgürlük ilanı’ olarak fazlasıyla değer
Bugünlerde captive portal’lar dış trafiğin neredeyse tamamını engelliyor ama hâlâ zayıf olan çok yer var
SoftEther öneririm — Azure Relay özelliği sayesinde beyaz liste kullanan ağlarda da iyi çalışıyor
Henüz iodine ile DNS üzerinden çift yönlü iletişimi denemedim ama yavaş olsa da çoğu durumda işe yarar gibi duruyor
Ödeme sürecini tekrar tekrar başlatırsan bunun üzerinden çıkış yapılabiliyor
Farklı portları denemek yüzünden başlangıç yavaştı ama başarı oranı şaşırtıcı derecede yüksekti
Ama bugünlerde çoğu yer yalnızca DNS trafiğine izin veriyor ve rastgele resolver’ları engelliyor
Eğer TCP-over-WhatsApp VPN yapılabilse gerçekten harika olurdu
DNS değil, HTTP(S)’i UDP tünelleme üzerinden geçiriyordum; Stansted Havalimanı’nda ücretsiz Wi-Fi’ın 30 dakikalık sınırı dolmadan kurulumu tamamladığımda epey gururlanmıştım
Web sitesindeki ciddi bir açığı dile getirince “önemliyse pentest’te çıkar” diyerek çok da umursamadılar
Pek etkilenmeden karşılıklı ayrıldık
Uçak içi Wi-Fi güvenliği aslında sadece gelir yaratma mekanizması; şirketin genel güvenliğinden ayrı bir konu
Birçok şirket yıllık pentest yaptırınca güvenlik işinin bittiğini sanıyor ama ürünü gerçekten tanıyan mühendisler yatırım onayı alamıyor
Teknoloji sektörü yüksek gelirli bir alan; Wi-Fi ücretini ödemek gerekir diye düşünüyorum
Trafiği başka düğümler üzerinden proxy’leyen bir araç; ağları anlamak için kendim yazdım
Bir amacı da Birleşik Krallık’taki yaş doğrulama yasasını aşmaktı
GitHub bağlantısı
Dünyadan kısa süreliğine kopmuş olmak hoşuma gidiyor. Bu yüzden herkesin ücretsiz Wi-Fi kullanmaya başlaması beni sevindirmiyor
Sen istemiyorsan bağlanmazsın. Başkalarının kullanması seni etkilemez
Ücretsiz mesajlaşma planını açtım ve WireGuard tüneli kullanıyorum; güvenlik duvarı sanki tamamen engelleyecek şekilde tasarlanmamış gibi
Daha önce denemiştim ama bende pek işe yaramamıştı