Özel güvenlik bağlantılarına herkese açık şekilde erişemezsiniz, değil mi?

Herkese açık olmayan özel güvenlik bağlantıları, gerçekten öyle mi?

• Popüler kötü amaçlı yazılım/URL analiz araçları olan urlscan.io, Hybrid Analysis ve Cloudflare Radar URL Scanner; bilgi toplamak ve paylaşmak için büyük miktarda bağlantıyı depolar.
• Bu hizmetlerin, kullanıcılar tarafından yanlışlıkla gönderilen veya hatalı yapılandırılmış tarayıcılar ve uzantılar tarafından herkese açık veri olarak taranan özel ve hassas bağlantıları depoladığı gerçeği yaygın olarak bilinmiyor.

Hangi bağlantılardan bahsediyoruz?

• Bulut depolama araçları (Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, AWS S3 vb.) kullanılarak paylaşılan dosyalar.
• Buluta bağlı NAS araçları (Western Digital Mycloud vb.).
• Kurumsal iletişim (Slido, Zoom, Onedrive, Airtable vb.).
• Parola sıfırlama bağlantıları, OAuth oturum açma bağlantıları vb.
• Bu hizmetlerin ortak noktası, rastgele tanımlayıcılar içeren tek bir özel bağlantıyla hizmete erişim sağlamalarıdır. Bazen parola veya parola ifadesiyle ek olarak korunurlar; bu durumda bağlantıya erişmek veri ifşasına yol açmaz.

Sorumlu kim olmalı?

• Hybrid Analysis ve urlscan.io'nun kullanım şartlarına göre, gönderilen içerikten kullanıcı sorumludur ve hassas bağlantıları inceleyip kaldıracak bir mekanizma yoktur.
• Bunu otomatik şekilde uygulamak da kolay olmayabilir.
• Bir güvenlik araştırmacısı olarak bu bağlantıların kaynağını tespit etmek zordur.

Biz tehdit avcılarıyız! Tüm bağlantılar bizimdir!

• urlscan Pro, ücretli kullanıcıların/şirketlerin Publicın yanı sıra Unlisted taramalara da erişmesine izin verir.
• Unlisted, herkese açık sayfalarda veya arama sonuçlarında görünmez, ancak urlscan Pro platformunun müşterileri tarafından görülebilir.
• TheHive'ın Cortex-Analyzers aracı, urlscan.io analizöründe bağlantıların unlisted olarak görünmesi için açıkça public:on yapılandırmasını kullanır.
• Veriler urlscan Pro kullanıcılarına açıkça yayımlanmasa da erişilebilir olduğundan, daha fazla hassas bilginin sızma riski vardır.

Hassas bağlantılar nasıl kaldırılabilir?

• Urlscan ve Hybrid Analysis, bağlantıların işaretlenip kaldırılmasına izin verir.
• Hybrid Analysis'te, herkese açık sandbox'a gönderilen tüm dosyalar aranabilir durumdadır ve tüm dünyaya açıktır.

Sonuç

• Bu sorunun sürmesi kaçınılmaz görünüyor; taramaları varsayılan olarak özel tutmak en iyi çözüm olabilir, ancak bu yaklaşım güvenlik topluluğunun tehdit istihbaratı ve analiz paylaşımı pratiklerinin amacıyla örtüşmez.
• Bu tür hizmetleri kullanırken taramanın görünürlüğüne dikkat edilmelidir.

Feragatname

• URL veritabanlarında bu bağlantılara/dosyalara erişmeyi seçerseniz, gerçek kötü amaçlı dosya ve bağlantılara karşı dikkatli olun.
• Bazıları yalnızca phishing girişimi olabilir ve gerçekten kötü amaçlı yazılım içerebilir.
• Bir sandbox ortamı kullanmanız önerilir.

Faydalı bağlantılar

• urlscan.io'nun SOAR spot yazısı: Chatty security tools leaking private data (2022)
• urlscan.io Search API Reference
• Falcon Sandbox Public API
• Cloudflare Radar URL Scanner

GN⁺'nin görüşü

• Bu yazı, güvenlik araçlarının hassas bilgileri nasıl yanlışlıkla açığa çıkarabildiğini göstererek hem güvenlik araştırmacıları hem de genel kullanıcılar için önemli bir farkındalık oluşturuyor.
• Bu tür sorunlar kullanıcı hataları veya araçların yanlış yapılandırılması nedeniyle ortaya çıkabilir; bu da güvenlik topluluğunda hassas bilgilerin işlenmesine dair daha fazla dikkat ve sorumluluk gerektirir.
• Yazı ayrıca, bireylerin ve şirketlerin kendi verilerini korumak için hangi önlemleri alması gerektiğinin önemini vurguluyor.
• Eleştirel bir açıdan bakıldığında, bu tür sızıntılar kişisel mahremiyetin ihlali ve şirket gizliliği için ciddi bir tehdit oluşturabilir; bu da güvenlik araçları ve hizmetlerinin güvenilirliğine dair soru işaretleri doğurabilir.
• Benzer işlevler sunan diğer projeler arasında VirusTotal veya Any.run gibi kötü amaçlı yazılım analiz platformları da bulunuyor; bu hizmetleri kullanırken verilerin herkese açık olup olmadığını her zaman dikkatle değerlendirmek gerekir.

[GN⁺]

Hacker News görüşü

• Temel sorun, bağlantıya erişim kontrolü olmaması; yalnızca herkese açık bir indeks bulunmadığı için özel olduğu varsayılıyor. AWS hesap kimliğinin bucket üzerinden keşfedilmesiyle ilgili bir konu Hacker News'te ilgi gördü ve yorumlardan çıkan ortak görüş, hesap tanımlayıcısının gizliliğini güvenliğin bir parçası olarak görmekten medet ummanın yanlış bir yaklaşım olduğuydu. Bu, sadece başka bir dorking yöntemi.

  • Bağlantının gizliliği: Bir bağlantının herkese açık olarak indekslenmediği için özel olduğunu varsaymak sorunludur. AWS hesap kimliğinin gizliliğine dayanmak güvenlik açısından doğru bir yaklaşım değildir ve bu yeni bir güvenlik sorunu değil, bir dorking biçimidir.

• Kişisel olarak paylaşılabilir bir bağlantı oluşturmak istiyorsanız, gizli bilgiyi URL'nin hash kısmında tutmanız gerekir. Hash, DNS sorgularına ya da HTTP isteklerine dahil edilmez. Örneğin links.com#<secret> biçimindeki bir bağlantı tarayıcının dışına çıkmaz. Hash kısmındaki veriyi URL-safe Base64 dizgesi olarak kodlamak iyi bir fikirdir.

  • Bağlantının güvenli paylaşımı: Gizli bilgiyi URL'nin hash kısmında saklayarak bağlantı güvenli biçimde paylaşılabilir. Bu yöntem, hash DNS sorgularına veya HTTP isteklerine dahil edilmediği için daha güvenlidir.

• Sınırsız kullanılabilen "özel" bağlantılara hep şüpheyle yaklaştım. Bu, yalnızca gizleme yoluyla güvenliktir. Google Docs'ta olduğu gibi, "URL'ye sahip olan herkes erişebilir" şeklinde açık bir seçenek olduğunda bu daha iyidir. Yazarın kurduğu sistemde kısa ömürlü signed URL'ler kullanılıyor ve bu URL'ler kullanıcıya doğrudan gösterilmiyor.

  • "Özel" bağlantılara dair şüphe: "Özel" bağlantılar gerçekte yalnızca gizleme yoluyla güvenlikten ibarettir; kısa ömürlü signed URL kullanmak daha güvenli bir yöntemdir.

• Hızlı bir yönlendirme döngüsünün parçası olmayan bağlantılar kopyalanıp paylaşılacaktır. URL'ler evrenseldir ve protokol üzerindeki kaynaklara erişimi kolaylaştırır. Kısa olmayan bir ömre sahip her şeye yönelik erişim kontrolü URL dışında yapılmalıdır. e2ee olmayan kanallarda bir bağlantı paylaşılırken, URL'ye ilk erişen taraf alıcı değil kanalın hizmeti olabilir. Kullanıcılara taramanın herkese açık olduğunu açıkça söylemek, bu tür tarayıcı araçların UX'ini iyileştirmeyecektir.

  • URL üzerinden erişim kontrolü: URL'ler kaynaklara erişimi kolaylaştırmak için paylaşılır; erişim kontrolü URL üzerinden değil başka yollarla yapılmalıdır. Tarayıcı gibi araçlar, herkese açık taramayı kullanıcıya bildirirse kullanıcılar hizmeti kullanmakta tereddüt edebileceğinden bu UX açısından faydalı olmayabilir.

• "E-posta tabanlı kimlik doğrulama" sorununa çözüm, hesap ve parola oluşturma adımı olmadan, URL yanlışlıkla paylaşılsa bile sorun yaratmayacak tek kullanımlık kodlar kullanmaktır. Kullanıcı "özel" bağlantıyı ziyaret ettiğinde site, zaman sınırlı tek kullanımlık bir kodu e-postayla yeniden gönderir ve kullanıcı e-posta sahipliğini doğrulamak için bu geçici kodu girer.

  • E-posta doğrulaması ve tek kullanımlık kodlar: E-posta tabanlı kimlik doğrulama sorununu çözmek için tek kullanımlık kodlar kullanılır; bu sayede URL yanlışlıkla paylaşılsa bile sorun çıkmaz.

• İnternette bir URL'nin rastgele bir dizgeden daha güçlü bir koruması yoksa, bunlar fiilen özel değildir. Bu, internete bağlı webcam'leri bulma hikâyesiyle aynı şey. Bunu zaten biliyor olmamız gerekirdi. "Sorumluluğu kim üstlenmeli" bölümünde bundan neden bahsedilmiyor?

  • URL'lerin özel olma niteliği: Bir URL'nin rastgele bir dizgeden fazlasıyla korunmaması durumunda özel sayılmaz; bu zaten uzun zamandır bilinen bir gerçektir.

• Konudan biraz sapıyor ama Cloudflare Radar'ın 1.1.1.1 üzerinden veri madenciliği yaptığına dair bir bağlantı var. 1.1.1.1'in kullanıcı verilerini hiçbir amaçla kullanmadığını sanıyordum?

  • Cloudflare Radar ve 1.1.1.1: Cloudflare Radar'ın 1.1.1.1 üzerinden veri madenciliği yaptığı iddia ediliyor; bu da 1.1.1.1'in kullanıcı verilerini kullanmadığı yönündeki mevcut algıyla çelişiyor.

• Zoom toplantı bağlantıları çoğu zaman sorgu parametresi olarak parola ekler. Bu bağlantı "özel ve güvenli" bir bağlantı mı? Parola olmadan "özel ve güvenli" bir bağlantı sayılır mı?

  • Zoom toplantı bağlantılarının güvenliği: Zoom toplantı bağlantısında parola bulunduğunda ve bulunmadığında güvenliğin nasıl değerlendirileceğine dair soru.

• Şu iki durumdan hangisinin daha güvenli olduğunu açıklayabilir misiniz?

  1. domain.com/login kullanıcı: John parola: 5 haneli rastgele parola
  2. domain.com/12자리 무작위 URL Her iki durumda da aynı rastgelelik / rate limiting korumasının olduğunu ya da hiç olmadığını varsayarsak, neden 1. seçenek 2. seçenekten daha güvenlidir?
  • Giriş güvenliği karşılaştırması: İki farklı giriş yönteminin güvenliğinin karşılaştırılmasına dair soru.

• private airtable.com uygulamasına yüklenen tüm medya/fotoğraflar herkese açık bağlantılardır; URL'yi bilen herkes kimlik doğrulama olmadan erişebilir.

  • Airtable.com'daki herkese açık bağlantılar: Airtable.com'a yüklenen medya/fotoğraflar herkese açık bağlantılardır; yalnızca URL'yi bilen herkes bunlara erişebilir.