Gizli güvenlik bağlantıları gerçekten herkese açık erişime kapalı mı?

 (vin01.github.io)
2 puan yazan GN⁺ 2024-03-08 | 1 yorum | WhatsApp'ta paylaş
  • urlscan.io, Hybrid Analysis, Cloudflare Radar URL Scanner gibi URL/kötü amaçlı yazılım analiz servisleri, tehdit istihbaratı paylaşımı için bağlantıları saklar; ancak kullanıcı hatası veya yanlış yapılandırılmış tarayıcılar nedeniyle hassas bağlantılar herkese açık veri olarak kalabilir
  • Dropbox, iCloud, AWS S3, Zoom, OneDrive, Airtable, parola sıfırlama bağlantıları, OAuth oturum açma bağlantıları gibi URL’nin kendisinin erişim yetkisi gibi kullanıldığı servisler özellikle etkilenebilir
  • Her bağlantı hemen açığa çıkmaz; ancak vergi belgeleri, faturalar, fotoğraflar, iş iletişimleri, onetimesecret ile paylaşılan sırlar, akıllı ev ve toplantı kayıtları gibi materyallerin gerçekten bulunduğu görülmüş
  • urlscan Pro, yalnızca Public değil Unlisted taramaları da ücretli müşterilere gösterir; TheHive’ın Cortex-Analyzers ayarlarında olduğu gibi bağlantıların istemeden unlisted olarak gönderildiği yollar olabilir
  • Son 24 saatte urlscan.io tarama sayıları Public 398.563, Unlisted 328.147, Private 955.432 idi; kanarya token deneyinde de gönderimden sonraki 1 saat içinde erişim doğrulandığı için tarama görünürlüğü yönetimi gerekir

URL analiz servislerinde kalan hassas bağlantılar

  • urlscan.io, Hybrid Analysis, Cloudflare Radar URL Scanner, URL ve kötü amaçlı yazılım analizi için çok sayıda bağlantı saklar
  • Sorun, bu depolara gizli ve hassas bağlantıların da girebilmesidir
    • Kullanıcı, bunun herkese açık bilgi hâline geleceğini bilmeden hassas bağlantıyı taramaya gönderir
    • Yanlış yapılandırılmış tarayıcılar veya uzantılar, e-postada taradıkları gizli bağlantıları herkese açık veri olarak gönderir

Açığa çıkabilecek bağlantılar ve materyaller

  • Bulunan bağlantılar, çeşitli servislerin paylaşım URL’lerini ve kimlik doğrulama ile ilgili URL’leri içerir
    • Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, AWS S3 gibi bulut depolama dosya paylaşımları
    • Western Digital Mycloud gibi bulut bağlantılı NAS’lar
    • Slido, Zoom, OneDrive, Airtable gibi kurumsal iletişim araçları
    • Parola sıfırlama bağlantıları ve OAuth oturum açma bağlantıları
  • Bu tür servisler, güvenlik için çoğu zaman rastgele tanımlayıcı içeren tekil gizli bağlantılarla erişime izin verir
  • Bazı bağlantılar parola veya passphrase ile ek olarak korunduğundan, yalnızca bağlantıya erişmek verinin hemen açığa çıkması anlamına gelmez
  • Gerçekte bulunan hassas içerikler şunlardı
    • Vergi belgeleri, faturalar, fotoğraflar, iş iletişimleri gibi gizli dosyalar
    • onetimesecret ile paylaşılan sırlar
    • Akıllı ev cihazı kayıtları
    • Bulutta saklanan toplantı kayıtları

Gönderim yolları ve sorumluluk boşlukları

  • urlscan.io’da doğrulanan birçok gönderimde falconsandbox etiketi vardı; bu da analiz kapsamının Hybrid Analysis tarafına kadar genişlemesine yol açtı
  • Cloudflare Radar da daha yaygın kullanılma potansiyeline sahip ve şimdiden bazı gizli bağlantıları herkese açık veriye dahil ediyor
  • Hybrid Analysis şartları, kullanıcı tarafından gönderilen içeriğin analiz edilebileceğini, yayımlanabileceğini ve paylaşılabileceğini; gönderilerde veya otomatik oluşturulan raporlarda tesadüfen yer alan bilgilerden sorumlu olmadığını belirtir
  • urlscan.io şartları da kullanıcı içeriği veya eylemlerinden sorumlu olmadığını, bir hesap altında yayımlanan içerik ve etkinliklerden kullanıcının sorumlu olduğunu belirtir
  • Mevcut içeriği inceleyip hassas bağlantıları işaretlemek veya kaldırmak için net bir mekanizma yok gibi görünüyor; bunu otomatikleştirmek de kolay olmayabilir
  • Positive Security’nin analizi, urlscan.io üzerinde kanarya token kullanarak otomatik kaynakları tespit etti ve e-postalardaki kötü amaçlı bağlantıları tarayan güvenlik araçlarının neden olabileceğini ele aldı
  • Aynı davranış kanarya bağlantılarıyla da doğrulandı

Unlisted taramalar ve urlscan Pro erişimi

  • urlscan Pro, ücretli kullanıcılara ve şirketlere Public’in yanı sıra Unlisted taramalarına kadar daha geniş bir tarama erişimi sağlar
  • urlscan.io’da Unlisted, herkese açık sayfalarda veya arama sonuçlarında görünmez; ancak urlscan Pro platformu müşterilerine görünür durumdadır
    • urlscan Pro müşterilerinin doğrulanmış güvenlik araştırmacıları veya itibarlı şirketlerle sınırlı olduğu belirtilir
  • TheHive projesinin Cortex-Analyzers bileşeni, istenmeyen bir açığa çıkma yolunu gösteren bir örnektir
    • urlscan.io analizöründe public:on ayarını açıkça kullanır
    • Bu ayar nedeniyle urlscan hesabı görünürlüğü Private olsa bile bağlantılar unlisted olarak görünebilir
    • İlgili kod Cortex-Analyzers’ın urlscan.py dosyasındadır
  • Bu durumda veri tamamen herkese açık olmasa bile urlscan Pro kullanıcılarına görünebilir; dolayısıyla daha hassas bilgilerin açığa çıkma ihtimali kalır

Tarama sayıları ve kanarya token sonuçları

  • Son 24 saat itibarıyla urlscan.io tarama sayıları şöyleydi
    • Public: 398.563 adet
    • Unlisted: 328.147 adet
    • Private: 955.432 adet
  • Kanarya token ile doğrulanan erişim sonuçları şöyleydi
    • urlscan.io’ya unlisted olarak gönderilen bağlantıya, gönderimden sonraki 1 saat içinde 12 kez erişildi
    • Hybrid Analysis’e tarayıcı yerine API ile gönderilen bağlantıya, gönderimden sonraki 1 saat içinde 10 kez erişildi
    • Bazı IP adresleri, iki servise gönderilen benzersiz bağlantılara aynı anda erişti ve kaynak IP anonimleştirme servisi kullandı
  • Söz konusu IP adresleri listesi ayrı bir dosya olarak yayımlandı

Hassas bağlantıları kaldırma ve kullanımda dikkat edilecekler

  • urlscan.io ve Hybrid Analysis, bağlantıları bildirip kaldırmak için süreçler sunar
  • Hybrid Analysis’te kaldırma ve paylaşım kapsamı daha karmaşıktır
    • Public Sandbox’a gönderilen tüm dosyalar aranabilir ve dünya genelinde erişilebilir olur
    • “Do not share my sample with the community” onay kutusu seçilse bile ekran görüntüleri ve gerçek rapor sunulmaya devam eder
    • “do not share” yalnızca gerçek girdi örneğine uygulanır
  • Bu servisleri kullanırken önce tarama görünürlüğü kontrol edilmelidir
  • Bu tür URL veritabanlarında bağlantılara veya dosyalara erişirken phishing girişimleri, gerçek kötü amaçlı dosyalar ve kötü amaçlı bağlantılarla karşılaşılabilir
  • Erişim gerekiyorsa sandbox ortamında kontrol edilmelidir

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-08
Hacker News görüşleri

  • Temel sorun, erişim kontrolü olmayan bağlantıların, herkese açık tanımlayıcı dizini olmadığı için özel sayılması
    Geçen ay da bucket üzerinden AWS hesap kimliği bulma konusu HN'de epey ilgi görmüştü[0] ve yorumlardaki ortak kanaat, hesap tanımlayıcısının gizli olduğu varsayımına dayanarak güvenlik beklemenin yanlış olduğu yönündeydi
    Aynı kavram burada da geçerli; bu yeni bir güvenlik sorunu olmaktan ziyade başka bir arama operatörü tabanlı keşif (dorking) yöntemi
    [0]: https://news.ycombinator.com/item?id=39512896

    • Sorun, bağlantıların sızması
      Teorik olarak 256 karakterlik onaltılık bir bağlantı, yani 1024 bit, 32 karakterlik kullanıcı adı ve 32 karakterlik paroladan tahmin edilmesi çok daha zor
      https://site.com/[256chars] için 2^1024 kombinasyon vardır; bu yüzden kaba kuvvet fiilen imkânsızdır
      Buna karşılık https://site,com/[32chars] ve 32 karakterlik parola 2^256 kombinasyon sunar; bu da neredeyse imkânsızdır ama öncekine göre daha olasıdır
      Bunu https://site,com/[32chars][32chars] gibi düşünmek gerekir
      Ancak ilki tahmin etmesi daha zor olsa da URL'ler, parolalara kıyasla çok daha sık sızar
    • Bir ayrıntıyı kaçırıyor olabilirim ama temel sorun, insanlar arasındaki özel mesajların özel kabul edilmesine rağmen gerçekte mesajı taşıyan platformun bu mesajları okuyup bağlantılara erişmesi gibi görünüyor
      Buradaki mesaj; e-posta, DM ve belgelere yapıştırılan bağlantıları da kapsayacak şekilde geniş anlamda kullanılıyor
    • Biraz konu dışı ama yakın zamanda bir danışmandan, her NAR dosya adında devasa bir hash bulunduğu için özel Nix closure'larını herkese açık erişilebilen bir S3 bucket'a koymanın sorun olmayacağı tavsiyesini aldım
      İçime sinmediği için sonunda başka bir yöntem seçtim ama URL'nin içinde bir “sır” bulunmasıyla, URL isteği sırasında gönderilen bir token içinde sır bulunması arasında pratikte ne kadar fark olduğunu düşünmeye devam ediyorum
      Benim vardığım sonuç, token'ların müşteri bazında verilebildiği ve erişim günlükleri izlenerek şüpheli davranış görülürse iptal edilebildiği
      Ayrıca başkalarının da söylediği gibi bu, dosya adı listesini gizli tutmayı ne kadar önemli gördüğünüze dair bir zihniyet farkı
      Amazon'ın hata yapabileceği ölçek düşünüldüğünde, herkese açık bucket'lardaki dosya adı listesinin kazara açığa çıkması kullanıcıların %99'unun önemsemeyeceği bir şey gibi duruyor; bu yüzden önceliği düşük olabilir
    • Eskiden çalıştığım şirket, bir müşteriyle çalışırken S3 bucket adı çakışması yaşamıştı; çünkü iki taraf da hyphenated-company-name biçiminin iyi bir S3 bucket adı olduğunu düşünmüştü
      Doğal olarak bizim şirket o yarışı kaybetti
      O günden beri AWS ile her çalıştığımda bucket adlarını genelde - biçiminde koyma dersi aklımda kaldı
      Gerçekten özel olması gerekiyorsa proje adını da şifreleyebilir ve bucket'ları “tanıdık” adlarla listeleyen bir betik sağlayabilirsiniz
      Hosting servislerinde her zaman tuhaf ödünleşimler vardır; teknik olarak kusursuz yöntem olan tamamen rastgele tanımlayıcılar, kusurlu ama açıklayıcı adlara göre çok daha fazla operasyonel yük getirebilir
    • Parola içeren özel bir bağlantıyla, bağlantıya gittikten sonra parola girilen bir site arasında fark olup olmadığını merak ediyorum
      Bitwarden Send, başkalarına iletebileceğiniz bağlantılar oluşturuyor ve # sonrasında uzun rastgele bir dize ekliyor
      Bunu düzenli kullandığım için burada bir güvenlik sorunu olup olmadığını bilmek isterim
      En azından bağlantı iptal edilebiliyor ve birkaç gün sonra otomatik süresi dolabiliyor; sıradan parolalar ise genelde böyle çalışmıyor

  • Özel paylaşım bağlantıları oluşturmak için URL'nin hash kısmında gizli bir değer saklayabilirsiniz
    Hash, DNS sorgularında veya HTTP isteklerinde gönderilmez
    Örneğin links.com?token= adresine gidildiğinde bu bağlantı, arama parametreleriyle birlikte gönderilir ve Cloudflare gibi aracı sistemlerde saklanabilir
    Buna karşılık links.com# adresine gidildiğinde hash kısmı tarayıcının dışına çıkmaz
    Hash kısmındaki verilerle çalışırken bunları URL Safe Base64 dizesi olarak kodlamak kullanışlıdır
    Yani akış JS Object ↔ JSON String ↔ URL Safe Base 64 String şeklindedir

    • HTTPS kullanılıyorsa parametre dizesi ve yol da şifrelenir; dolayısıyla o sırrı okuyabilmek için ilgili aracının trafiği çözebilmesi gerekir
      Geri kalanı doğru, sadece bu HTTPS şifrelemesi nüansını eklemek istedim
    • Büyük bir uyarı var: O sayfada çalışan, görünüşte zararsız JavaScript bile fragment'ı internette herhangi bir yere gönderebilir
      Bunu fragment'a koymak yardımcı olur ama kusursuz değildir
      Bunu sadece teorik olarak söylemiyorum; özel token'ların fragment'tan bu şekilde sızdığını gerçekten birkaç kez gördüm
    • Benim bilmediğim, alan adı kısmından fazlasını sorgulayan bir DNS özelliği mi var?
      [https://example.com?token=](<https://example.com?token=<secret>>;) için DNS sorgusunun yalnızca “example.com” adına gitmesi gerekir
    • Bu sorunu nasıl çözeceğini düşününce özellikle e-posta tabanlı oturum açma veya hesap sıfırlama akla geliyor
      E-postadaki bağlantıları takip eden botlar JavaScript çalıştırıyor mu? JavaScript'in tetiklediği bir POST ile gerçek işlemin etkinleşmesi riski var mı?
    • Bilgi olarak, buna fragment denir

  • Hızlı yönlendirme döngüsünün bir parçası olmayan bağlantılar, paylaşım için kaçınılmaz olarak kopyalanıp yapıştırılabilir
    URL'ler zaten bunun için vardır; evrenseldir ve hangi protokolle sunulursa sunulsun bir kaynağa kolay erişim sağlar
    Kısa ömürlü olmayan şeyler için erişim kontrolü URL'nin dışında yapılmalıdır
    Uçtan uca şifreli olmayan bir kanalda bağlantı paylaşırsanız, o URL'ye ilk erişen taraf alıcı değil kanal hizmetinin kendisi olur
    Bu, Bitwarden'ın kullanıcı deneyimi için favicon getirmesi gibi meşru olabilir ya da Facebook Messenger tarayıcısının özel mesajlarda ne paylaşıldığı hakkında daha fazla bilgi istemesi gibi kötü niyetli olabilir
    Bu tür tarayıcı araçları kullanıcı deneyimini daha iyi hâle getirmeyecektir
    Tarama sonuçlarının ifşa edildiği açıkça belirtilse bazı kullanıcılar hizmeti kullanmadan önce yeniden düşünebilir; bu da ister ücretsiz kullanıcılar ister pro lisans sahipleri olsun, işletme açısından kötüdür

  • Sınırsız kullanılabilen “özel” bağlantılar her zaman biraz şüpheli gelmiştir
    Sonuçta bu, belirsizliğe dayanan güvenliktir
    Google Dokümanlar gibi bir şeyi paylaşırken en azından “URL’ye sahip olan herkes erişebilir” diye açıkça belirtilen bir seçenek vardır
    Kendi kurduğum sistemlerde bu tür bir şeye ihtiyaç duyduğumda genelde ömrü sadece birkaç dakika olan imzalı URL’ler kullandım
    URL genelde bir uygulama ayrıntısıdır ve kullanıcıya doğrudan gösterilmez, ama tarayıcının debug ekranında görülebilme ihtimali vardır

    • Anahtar uzayı yeterince büyükse, özel bağlantı ile kullanıcı adı·şifre ya da API anahtarıyla korunan bağlantı arasında işlevsel olarak fark yoktur
    • Google Dokümanlar paylaşımı ne yazık ki belge kimliğine dayalı olduğu için erişim yetkisini yeni bir URL ile yeniden etkinleştiremezsiniz

  • İnternette böyle bir şey URL içindeki rastgele bir dize dışında hiçbir şeyle korunmuyorsa, gerçekte özel değildir
    Bu, aratınca çıkan internete bağlı web kameralarıyla aynı hikâyedir
    Bu zaten bilinen bir şey değil miydi? “Kim sorumlu?” bölümünde bunun neden hiç ele alınmadığını anlamıyorum

    • Bu tür bağlantılar, “kullanım senaryosuna uygun güvenlik yeterlidir” bağlamında çok faydalıdır
      Her şey için en üst düzey güvenlik gerekmez ve bazı durumlarda geniş çaplı paylaşımı engelleyen bir bariyer yeterlidir
      Örneğin bir fotoğraf galerisinde “bağlantı paylaşımı oluştur”a basıp birine fotoğraf bağlantısı gönderiyorsam, o kişinin şifre girmesini istemem
      Bağlantıyı açınca fotoğraf görünmelidir ve bu amaç için sorun yoktur
      Buradaki örneklerden biri tam olarak böyle bir durum ve o kullanım senaryosuna uygundur
      Gizlilik kaygıları açısından da, giriş süreci olsa bile son kullanıcı o noktada ekran görüntüsünü yeniden paylaşabilir
      Güvenlik kullanım senaryosuna uygundur
      Kullanıcının artık fotoğraf bağlantısına sahip olduğu ve bunu yeniden paylaşabileceği, ama bilerek yapmayacağına güvenilen bir durumdur
      Buradaki büyük sorun, bağlantının kendisinden çok, güvenlik analiz araçlarının kullanıcının e-postayla aldığı tüm bağlantıları tarayıp o topluluktaki diğer kullanıcılar için de erişilebilir hale getirmesidir
      Bu, birine fotoğraf gönderirken amaçladığımdan çok daha büyük bir yeniden paylaşımdır

  • Bu e-posta tabanlı kimlik doğrulama sorununun geçici çözümü, şifreli hesap oluşturmaya kadar gitmeden tek kullanımlık geçici kod kullanmaktır
    Böylece URL yanlışlıkla paylaşılırsa büyük bir sorun olmaz

    1. Kullanıcı “özel” bağlantıyı ziyaret eder; bu, e-postayı yeniden girmeyi isteyen herkese açık bir bağlantı da olabilir
    2. Site, süre sınırlı tek kullanımlık bir kodu kullanıcıya yeniden e-postayla yollar
    3. Kullanıcı geçici kodu girerek e-posta sahipliğini doğrular
    4. Akış HTTP çerezi ya da oturum verisiyle sürdürülür ve e-posta hesabı sahibinin sürece dahil olduğuna dair makul güven elde edilir

  • Konu dışı ama bağlantı Cloudflare Radar’a gidiyor ve bu servis apparently 1.1.1.1 verisini madencilik yapar gibi kullanıyor görünüyor
    1.1.1.1’in kullanıcı verilerini hiçbir amaçla kullanmadığını sanıyordum

    • Cloudflare bu veriyi satmıyor ya da pazarlama için kullanmıyor, ama o adresin elde edilme nedeni zaten APNIC’in 1.1.1.1’e gelen gürültü trafiğini incelemek istemesiydi

  • Daha akıllı biri açıklasa iyi olur. Şunların farkı nedir?

    1. domain.com/login user: John password: 5 char random password
    2. domain.com/12 char random url
      İkisinde de aynı brute-force koruması veya rate limit olduğunu ya da ikisinde de olmadığını varsayarsak, neden 1, 2’den daha güvenlidir?
    • Bilgi teorisi açısından fark yoktur
      Pratikte ise vardır
      Sahipliğe dayalı sırlar ile bilgiye dayalı sırlar farklıdır
      URL sahip olunan bir şeydir; erişilebilen bir yerde bırakırsanız çalınabilir
      Şifre ise bildiğiniz bir şeydir ve iyi yönetirseniz çalınmaz. Tabii kurşun boru saldırısı hariç
      Bir başkası da biyometri temellidir; retina ya da parmak izi taraması buna girer
    • Bu yazının kendisi de sebebin bu olduğunu gösteriyor
      (1) kimlik doğrulama için ayrı bir kanaldan bilgi gerektirir ve insanlar bunu güvenli tutmaya alışkındır
      Buna karşılık (2)’deki URL, URL gibi muamele görür
      URL’ler sık sık loglanır, kaydedilir, paylaşılır ve oradan oraya aktarılır
      Mesela şirket güvenlik duvarı bir hizmete girişte kullanılan kullanıcı adı ve şifreyi kaydetse bunun açıkça kötü olduğu düşünülür, ama erişilen URL’yi kaydetmek çoğu kişiye normal görünebilir
      Bu sadece bir örnek; TLS’in uçtan uca garantileri nedeniyle aslında ikisine de erişilememesi gerekir
    • İki nokta var
      1. “Şifre” kelimesi, insanların bunu rastgele yerlere yapıştırma ihtimalini azaltan sihirli bir kelimedir
      2. Kullanıcı adı ve şifre genelde birlikte kopyala-yapıştır yapılmaz ve bunları yan yana saklamanın standart bir yolu da yoktur; yani iki ayrı bilgi parçasıdır
    • Bu yazının bağlamında fark, şirketin ya da kullanıcının kullandığı güvenlik tarama yazılımının e-postadaki 12 karakterlik bağlantının bir kısmını indekslemesi ve bazen bunu herkese açık tarama sonuçlarına koyabilmesidir
      Ayrıca domain.com/12-char-password HTTPS olmadan istenirse, sonradan yönlendirme olsa bile ilk istek şifrelenmeden gider ve ortadaki adam saldırısına açık olur
      Buna karşılık giriş sayfasında şifre gönderiminin yalnızca HTTPS üzerinden yapılmasını garanti etmenin daha çok yolu vardır
    • Bir zamanlar kimlik doğrulama token’ını sorgu parametresi olarak koymanın sorun olup olmadığını araştırmıştım
      Büyük sorunlardan biri, birçok logging uygulamasının tam URL’yi bir yerlere kaydetmesi ve bunun fiilen “şifreyi” loga yazmak anlamına gelmesidir

  • Özel bir airtable.com uygulamasına yüklenen tüm medya ve fotoğraflar herkese açık bağlantıdır
    URL’yi bilen herkes kimlik doğrulama olmadan erişebilir

    • CDN veya API’den görsel çeken web geliştiriciler için bu bir ikilemdir
      Normal image tag, API isteğinde fetch() ile yapılabildiği gibi isteğe token içeren bir Authorization header ekleyemez
      Mümkün seçenekler yalnızca URL’ye token eklemek ya da çerez tabanlı kimlik doğrulama kullanmaktır
      Çerez tabanlı kimlik doğrulama yalnızca CDN aynı alan adındaysa çalışır ve alt alan adı bile çoğu durumda sorun olabilir
    • CDN kullanan uygulamalarda bu sadece airtable’a özgü değil, oldukça yaygın bir yöntemdir
      Potansiyel olarak sorun yaratabileceğine katılıyorum

  • Zoom toplantı bağlantılarına çoğu zaman parolalar sorgu parametresi olarak eklenir
    Bu bağlantı “özel güvenli” bir bağlantı mı? Parolası çıkarılmış bağlantı “özel güvenli” bir bağlantı mı?

    • Parola her toplantı için rastgele ise URL bağlantısı da o kadar kötü sayılmaz
      Çünkü bu URL başka bir yerde görünene kadar o toplantı muhtemelen çoktan bitmiş ve ortadan kalkmış olur
      Ama pratikte kimse bunu umursamaz ve şunu bunu girmek zorunda kalmadan “tıklayıp katılmak” ister
      Önceki “yalnızca toplantı kimliği kullanma” yöntemi ise fazla kolay tahmin edilebiliyordu