- Ev tipi NAS cihazlarının web arayüzünün, yalnızca iç kullanım için olan ana makine adlarını dış servislere gönderdiği bir durum keşfedildi
- NAS web arayüzüne gömülü sentry.io hata raporlama betiği, yığın izleriyle birlikte iç ana makine adını dışarıya gönderiyor
- sentry.io tarafının bu ana makine adına ters yönde TLS bağlantısı kurmayı denediği, ancak gerçek bir istek göndermediği garip bir davranış gözlemlendi
- Önceden yapılandırılmış wildcard DNS sayesinde sızıntı tespit edilebildi; hassas ana makine adları kullanıldığında ciddi bilgi ifşası riski bulunuyor
- Bu mekanizma kötüye kullanılırsa rastgele ana makineler için DNS taraması tetiklenebilecek potansiyel bir güvenlik sorunu ortaya çıkıyor
NAS kurulumu ve iç ana makine adı yapılandırması
- Bir NAS cihazı satın alınıp sürücüler takıldı ve ev ağına bağlandı; sistem HTTPS modunda çalıştırıldı
- Genel internette anlamsız bir alan adının alt alt bölgesi için (ör.
*.nothing-special.whatever.example.com) wildcard TLS sertifikası kuruldu
- Tarayıcıdan erişmek için
/etc/hosts dosyasına 172.16.12.34 nas.nothing-special.whatever.example.com gibi yalnızca yerel kullanıma yönelik bir kayıt eklendi
Dışarıdan gelen beklenmedik erişimin fark edilmesi
- NAS kurulduktan birkaç gün sonra, aynı ana makine adına dış dünyadan istekler gelmeye başladı
- Bu ana makine adı, yalnızca dizüstü bilgisayarın
/etc/hosts dosyasında bulunan tamamen iç kullanıma özel bir addı
- Önceden
*.nothing-special.whatever.example.com tamamı için, kendi yönettiği makineye giden bir wildcard DNS kaydı ayarlanmış olduğundan sızıntı tespit edilebildi
- NAS her yüklendiğinde bir GCP ana makinesi, SNI içinde bu iç ana makine adını sunarak bağlantı kurmayı denedi
Sızıntının nedeni: sentry.io hata raporlaması
- NAS web arayüzünde phone home işlevi bulunuyor ve bunun bir parçası olarak sentry.io'ya yığın izleri gönderiliyor
- Tarayıcı sentry.io'ya geri çağrı yaparken, iç depolama cihazı için kullanılan ana makine adını da birlikte iletiyor
- sentry.io tarafının bu ana makine adına ters bir TLS bağlantısı oluşturduğu, ancak gerçekte hiçbir HTTP isteği göndermediği doğrulandı
Güvenlik sonuçları ve alınan önlemler
- Ana makine adı hassas bilgi içeriyorsa (ör.
mycorp-and-othercorp-planned-merger-storage gibi bir ad), ciddi bilgi sızıntısı riski oluşuyor
- Bu sentry raporlama mekanizması kullanılarak rastgele dış ana makineler için DNS taraması tetiklemek mümkün olabilir (somut yöntem okura bırakılmış)
- Önlem olarak Little Snitch çalıştırılıp ilgili alan adının tamamı tüm uygulamalar için engellendi
1 yorum
Hacker News yorumları
İnsanlar meseleyi yanlış anlıyor gibi görünüyor. Bu bir CT log sorunu değil, wildcard sertifika ile ilgili
Sentry, istemci tarafı trace’leri toplarken isteğin gönderildiği host adını çıkarıp onu yeniden poll etmeye çalışmış ve reddedilmiş
Host adları özünde özel bilgi değildir
DNS sorguları veya TLS sertifikaları gibi çeşitli yollarla dışarı sızar
Özel servisleri gizlemek istiyorsanız, host adı yerine URL yolu içine sır koymak daha iyidir
Örneğin
fileservice.example.com/my-hidden-service-007-abc123/gibi olursa yalnızca HTTPS üzerinden taşınır ve maruziyet çok daha az olur“clown GCP Host” ifadesinin teknik bir terim olup olmadığını merak ettim. Meğer yazar cloud’la alay etmek için böyle yazmış
Asıl mesele, NAS web arayüzünün logları Sentry’ye gönderirken iç host adlarını da içermesiymiş
Ben olsam böyle bir durumda güvenilir bir açık kaynak işletim sistemi ile değiştirir ya da PiHole gibi DNS engelleme ile Sentry çağrılarını keserdim
Birisi, yerel DNS ve TLS proxy kullanarak dışarı giden trafiği tamamen engellediğini anlattı
Bu tür örnekler yüzünden ben uBlock Origin’i web güvenliği için asgari standart görüyorum
Çoğu web sayfasının tonla üçüncü taraf script yükleyip veri sızdırması artık çok ciddi bir sorun
Kökten çözüm değil ama şu anda yapabileceğimiz en iyi şey bu
Bu tür sorunları önlemek için öne bir Nginx reverse proxy koyup CSP header eklemek iyi olur
Bu, NAS’ın kendi başına dışarı istek atmasını durdurmaz ama tarayıcının onun yerine istek göndermesini engelleyebilir
Örneğin Steam avatar isteği (
https://avatars.steamstatic.com/HASH_medium.jpg) de CSP politikasıyla engellenebilirGerekirse yalnızca bazılarına izin verilebilir. Ayrıca Referrer-Policy: no-referrer ekleyerek host adının harici loglarda görünmesini engellersiniz
Ben Synology NAS aldım ve bunu birkaç kez pişmanlıkla düşündüm
Topluluk yazılımları dışında yapılabilecek şey neredeyse yok
Let's Encrypt ile SSL kurmak bile karmaşık ve yollar standart dışı olduğu için ayarın nerede olduğunu bulmak zor
Eski rsync sürümü, eksik varsayılan araçlar gibi pek çok şikayetim var. Keşke Linux veya BSD tabanlı bir NAS kullansaydım
Yakın zamanda Sentry kurdum; bu sistemin otomatik uptime monitoring ayarlamaya çalışan bir özelliği var
Bir host algılarsa periyodik ping atıyor ve birkaç gün boyunca stabil yanıt alırsa “Bu host için uptime monitoring ayarlayalım mı?” diye bildirim gösteriyor
Ben şahsen Sentry ile ilgili tüm domain’leri engelliyorum
Genel bir çözüm değil ama benim ortamımda en iyi seçenek bu
Reverse DNS sunucuları, iç ağ adreslerini (ULA, RFC1918) bile çözmeye çalışıyor gibi göründükleri durumlar sık görülüyor
Bu veriler başka bilgilerle birleştirilirse iç durum hakkında çıkarım yapılabilir
Hatta “darknet veri toplama sırasında UDP ses trafiği bile yakalandı” denmiş
Geçmişte Heroku’da benzer bir durumu incelemiştim
Yeni bir uygulama oluşturduğunuzda rastgele bir subdomain veriliyor ve daha DNS sorgusu bile yapılmadan hemen zafiyet tarayıcılarından istekler gelmeye başlıyor
Heroku’ya sorduklarında, bunun yeni uygulama URL’sinin Certificate Transparency (CT) loglarında yayımlanmasından kaynaklandığını söylemişler
Certificate Transparency nasıl çalışır bağlantısı da paylaşılmış