Soyut
Keybase, Onename ve Blockstack gibi güven ağı hizmetleri (WOT), bireylerin web üzerindeki kimliklerini doğrulamayı vaat ediyor. Web’deki birçok uygulama tutarlı olmadığından, bu durum genellikle istenmeyen davranışlara ve dolayısıyla güven ağı hizmetlerinde güvenlik açıklarına yol açar. Bu yazı, WOT hizmetlerinin güvenliği konusunda araştırma yaparken karşılaştığım üç saldırı vektörünü analiz ediyor.
WOT Hizmetlerinin Arkasındaki Teknoloji
WOT hizmetleri, kullanıcıların token oluşturmasına ve bunları kişisel sayfalarına (örn. GitHub profili) yerleştirmesine olanak tanır. Hizmet daha sonra bir kazıyıcı kullanarak jetonu arayacak ve jeton geçerliyse kullanıcının aslında bu harici sayfanın sahibi olduğunu gösterecektir. Bu yöntemin arkasındaki fikir, kullanıcıların web üzerindeki hangi sayfaların kendilerine ait olduğunu görüntüleyebilmeleri ve ardından WOT hesaplarını tüm bu harici hizmetlere bağlayabilmeleridir. Bunun da ötesinde, doğrulama belirteçlerinin herkesin erişimine açık olması gerektiğinden, diğer kullanıcılar belirteci içeren sayfayı ziyaret ederek kanıtın meşru olduğunu doğrulayabilir.
Attack Vector One – İçeriğin Zaman Çizelgesine Göre Dağılımı
Web’de birçok profil tabanlı uygulama, başka birinin girişini kişisel zaman çizelgenizde paylaşarak içeriğin yeniden dağıtılmasına olanak tanır; Twitter’da kullanıcılar bunu yapabilir. retweetle içerik ve GitHub’da insanlar şunları yapabilir: çatal projeler. Bazı WOT hizmetleri kullanıcının kimliğini doğrulamak için herkese açık bir giriş veya gönderi kullandığından, kendime, bir saldırganın zaman çizelgesine gönderilen bir jetonu paylaşmalarını sağlayarak başka birinin hesabının sahipliğini talep etmenin mümkün olup olmayacağını sordum. Benim için özel bir hizmet göze çarpıyordu: Keybase gibi WOT uygulamalarının kullanıcıların doğrulama jetonunu GitHub özet dosyasına yerleştirmesini gerektirdiği GitHub. GitHub’da fark ettiğim ilginç davranış, bir kullanıcı bir Özeti çatalladığında, özün yalnızca kullanıcının zaman çizelgesinde görüntülenmesi değil, aynı zamanda orijinal yazarın kullanıcı adını paylaşanın kullanıcı adıyla değiştirmesidir.
Savunmasız hizmetlerden biri Keybase’di; burada bir saldırgan kurbanı GitHub özünü çatallamaya ikna ederse kurbanın GitHub kullanıcı adının sahibi olduğunu iddia edebilirdi. Üstelik Keybase, doğrulama pasajının değiştirilmesine izin vererek saldırganın jetonu bir HTML yorumunda gizlemesine olanak tanıdı.
Keybase’e karşı bu tekniğin kullanıldığı örnek bir saldırı şu şekilde gerçekleşebilir:
- saldırgan adresinden bir doğrulama jetonu talep ediyor Anahtar tabanı için kurbanın GitHub kullanıcı adı;
- Anahtar tabanı şunu ister saldırgan doğrulama jetonunu bir yere yerleştirmek için
keybase.mdana fikir; - saldırgan bir yaratır
keybase.mddoğrulama belirtecini bir HTML yorumunda gizleyen Gist; - kurban çatallar saldırganın GitHub’un özeti;
- saldırgan talimat verir Anahtar tabanı doğrulamak için
/./keybase.md
Sonuç olarak saldırganın Keybase hesabı, kurbanın hesabının kendisine ait olduğunu belirtiyor. Daha da kötüsü, Keybase’in, kullanıcıların belirli uygulamalara (örn. GitHub, Twitter, Hacker News, vb.) göz atmasına ve Keybase’deki kullanıcıya profil sayfası aracılığıyla mesaj göndermesine olanak tanıyan bir tarayıcı uzantısı vardır – uzantı, ekrana küçük bir mesajlaşma penceresi ekler. kullanıcının profili. Keybase’de hesabın sahibi olduğu doğrulanan hesaba mesajlar gönderilir. Bu, uzantının kullanıcıyı hedeflenen alıcıya mesaj gönderdiğini düşünmesi için kandıracağı, ancak kurbanın kullanıcı adını kontrol ettiği için tüm mesajların saldırganın gelen kutusuna düşeceği anlamına gelir.
Blockstack ve fireblock.io da bu saldırı vektörüne karşı savunmasızdı. Çoğu durumda, düzeltme, GitHub’un Gist API’sini kullanarak GitHub’un bir çatal olup olmadığını doğrulamaktan ibaretti.
İkinci Saldırı Vektörü – Ad alanı saldırıları
Bazı WoT hizmetleri, doğrulama jetonunun belirli bir dosya adına yerleştirilmesini gerektirir. Örneğin Keybase, önceki bölümde belirtildiği gibi GitHub doğrulama belirteçlerinin GitHub Gist’lerine yerleştirilmesini gerektirir. keybase.md. Web varlıklarında Keybase, dosyanın adlandırılmasını gerektirir keybase.txt ve üst düzey dizinin altına yerleştirilir veya .well-known yol. Arkasındaki sebep .well-known RFC5785’teki öneri, dosya adı çakışmalarını ve kök dizinin tıkanmasını önlemektir. WOT hizmetleri söz konusu olduğunda ilki özellikle ilgi çekicidir çünkü bir saldırgan bir web sitesindeki dosya adını kontrol edebilirse, potansiyel olarak alanın sahipliğini iddia edebilir. Liberapay.com ve Keybase’de böyle bir durum yaşandı. Açık kaynaklı bir bağış platformu olan Liberapay, kullanıcı adlarının nokta içermesine kısıtlama getirmedi; bu nedenle dosya uzantıları içeren kullanıcı adları oluşturulabilir. Security.txt projesi için bir profil sayfası (https://liberapay.com/security.txt) oluşturduğumda bu bana açıkça göründü. adında bir kullanıcı oluşturdum keybase.txt ve Keybase doğrulama pasajını profilin açıklamasına yerleştirdi. Bu, liberalapay.com’un sahipliğini talep etmemi sağladı. Keybase, keybase.txt dosyasının içerik türünü doğrulamadı ve hatta belirtecin bir sayfaya gömülü olmadığından bile emin olmadı.
Saldırı Vektörü Üç – Yönlendirmeler
Liberapay’in sahipliğini talep ettikten sonra.com Liberapay’in bunu fark ettim.org Liberapay’e yönlendiriyor.com. Bir sonraki saldırı, Liberapay için oluşturulan bir doğrulama jetonunun kullanılmasından oluşuyordu.org Liberapay’e gömülü.com Liberapay’in mülkiyetini talep etmek.org. Keybase’in kazıyıcısı körü körüne yönlendirmeyi takip edecek ve hedef ana bilgisayarla eşleştiğinden emin olmak için son uç noktayı doğrulamayacaktır. Keybase, Liberapay’i talep edecek.org/keybase.txt Liberapay’e yönlendiriyor.com/keybase.txt nerede geçerli keybase.txt dosya yer almaktadır.
Aklıma gelen makul bir saldırı senaryosu, bu tekniği kullanarak markalı URL kısaltıcıları talep etmekti.
Çözüm
Bu saldırı vektörlerinden etkilenen tüm hizmetlere bilgi verildi ve bildirilen sorunların çoğu derhal çözüldü. Keybase, 2 ve 3 numaralı saldırı vektörlerine karşı savunmasız durumda; anladığım kadarıyla bu sorunları çözmeyi planlamıyorlar. Etkilenen tüm tarafların yanıt sürelerinden çok etkilendim ve gelecekte onlarla tekrar çalışmayı sabırsızlıkla bekliyorum. Bu araştırma sonucunda mantık kusurlarını bulma bağımlısı oldum.
Güncelleme (16 Şubat 2018 Cuma): @LewisBugBounty yukarıda teorileştirdiğim gibi URL kısaltıcıların sahipliğinin iddia edilebileceğini gösterdi: Cıvıldamak.
