İsveç Banka Kimliği, İsveç'te ikamet edenlerin tamamı olmasa da çoğu tarafından internet sağlayıcıları, çevrimiçi bankacılık hizmetleri, bahis siteleri ve özellikle resmi web siteleri gibi birden fazla hizmette kimlik doğrulaması yapmak için kullanılan bir dijital kimlik biçimidir. Ben de İsveç'te yaşadığım ve hacker zihniyeti sürekli beynimde uğuldadığı için bunun güvenlik araştırması yapmak için çok ilginç bir alan olduğuna karar verdim. Bu yazıda BankID'nin kimlik doğrulama protokolünün güvenli olmayan bir şekilde uygulanması nedeniyle çoğu İsveç servis sağlayıcısında mevcut bulduğum yeni bir güvenlik açığını sunacağım. Böyle bir protokolün nasıl çalıştığını, savunmasız bir yapılandırmanın neye benzediğini, bundan nasıl yararlanılacağını, nasıl düzeltileceğini ve son olarak bu tür saldırıların eID'lerin genel uygulaması için ne anlama geldiğini kısaca ele alacağım. BankID Kimlik Doğrulama Protokolü BankID, kullanıcının cihazına yüklenen ve bir İsveç bankasından istenerek elde edilen bir hizmettir; İsveç (kişisel bir mali kodunuz) olması koşuluyla. Uygulama kullanıcının cihazına kurulur ve mali koduna bağlanır, esasen kullanıcının kimliğini böyle bir uygulamaya bağlar. Elektronik kimlik belirleme sistemleri genellikle bu şekilde çalışır: Devlet tarafından yetkilendirilmiş ve güvenilir bir üçüncü taraf, belirli bir kişiye bağlı bir yazılım parçası dağıtır ve daha sonra hizmetler, kullanıcılarının kimliklerini doğrulamalarına olanak sağlamak için bu yazılım parçasının sağlayıcısıyla bütünleşir. Hizmetlerin kişilerin kimliklerini kolayca doğrulamasını sağlayan paylaşılan bir güven modeli olan platform. kişisel numaranız BankID de farklı değil ve kimlik doğrulama akışlarını BankID ile kolayca entegre edebilmeleri için bundan sonra Güvenen Taraf (RP) olarak anılacak olan bu tür hizmetler için belgeler sağlıyor. . https://www.bankid.com/en/utvecklare/guider/teknisk-integrationsguide/rp-introduktion BankID ile bir kullanıcının kimliğini doğrulamak için iki ana akış kullanılır: Aynı cihazda kimlik doğrulama Başka bir cihazda kimlik doğrulama Bu ikisini yakında tekrar ele alacağız, ancak her iki akış da RP'nin, bir kimlik doğrulama siparişi başlatmak için BankID'nin API'sine bir istek göndermesiyle başlar. Bu gönderi isteğinde RP, oturum açmaya çalışan kullanıcının IP'sini içeren parametresini belirtmelidir, bu daha sonra raporda önemli olacaktır. endUserIp /auth API uç noktası şunun gibi bir yanıt verecektir: HTTP/1.1 200 OK Content-Type: application/json { "orderRef":"131daac9-16c6-4618-beb0-365768f37288", "autoStartToken":"7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6", "qrStartToken":"67df3917-fa0d-44e5-b327-edcc928297f8", "qrStartSecret":"d28db9a7-4cde-429e-a983-359be676944c" } , RP'nin kimlik doğrulama durumunu kontrol etmek ve daha sonra ihtiyaç duyduğu kullanıcı bilgilerini o kişiden almak için uç noktasına karşı kullanabileceği bir tanımlayıcıdır orderRef /collect , RP tarafından tıklandığında BankID uygulamasını açacak ve kullanıcıdan kendi kimliğini doğrulamasını isteyecek oluşturmak için kullanılan bir belirteçtir ( ) autoStartToken derin bir bağlantı Bu gerçekten önemli olacaktır ve aşağıda ele alınacaktır ancak yürütülen güvenlik araştırması açısından kesinlikle önemli değildir. qrStartToken qrStartSecret Kullanıcının IP'sine ek olarak, bir RP, kimlik doğrulama sırası için BankID uygulamasında görüntülenecek metin ve de dahil olmak üzere daha fazla parametre belirleyebilir. kimlik doğrulama gereksinimleri Kimlik doğrulama gereksinimleri arasında, bu yazının odaklanacağı olanlara denir; bunlar, RP'nin, kullanıcı tarafından iki akıştan hangisinin seçildiği BankID ile iletişim kurmasına olanak tanır. sertifika politikaları Aynı cihazda kimlik doğrulama Bir kullanıcı aynı cihazda BankID kullanarak kimlik doğrulaması yapmayı seçtiğinde, RP şuna benzeyen bir derin bağlantı oluşturmak için kullanır: . Bu derin bağlantı daha sonra kullanıcının işletim sistemi tarafından alınır ve BankID uygulamasına aktarılır. autoStartToken bankid:///?autostarttoken=7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6&redirect=https://service.com/login Bu akışı araştırırken, parametresinin BankID tarafından doğrulanması olmadığından bir güvenlik açığı bulundu. Bu ek hatanın neden oturum ele geçirme saldırısını daha da güçlü hale getirdiğini daha sonra anlatacağım. redirect Açık Yönlendirme Başka bir cihazda kimlik doğrulama Bir kullanıcı başka bir cihazda BankID kullanarak kimlik doğrulaması yapmayı seçtiğinde, RP, kullanıcı tarafından Mobil BankID'sini kullanarak taranabilecek dinamik bir QR kodu oluşturmak için (yukarıda belirtilen uç noktasından sonraki çerçevenin verilerini alarak) ve kullanır. başvuru. /collect qrStartToken qrStartSecret Sertifika Politikaları Bunlar, bir kimlik doğrulama emri başlatılırken RP tarafından belirtilmelidir ; kimlik avını azaltmak amacıyla, akışın eşleşmemesi durumunda BankID'nin bir kimlik doğrulama girişimini reddetmesine olanak tanır. Örneğin, kullanıcı "aynı cihazda kimlik doğrulama"yı seçerse, RP bunu BankID'ye iletmelidir; böylece kimlik doğrulama Mobil BankID'de ve/veya QR kodu kullanılarak denenirse uygulama bunu reddedebilir. GEREKLİdir Bunlara ek olarak, kimlik doğrulama tamamlandıktan sonra RP, BankID uygulamasını açmak için kullanılan API uç noktasından getirebilir. Daha sonra bu, kullanıcının “aynı cihazda kimlik doğrulamayı” seçmiş olması durumunda, kullanıcının RP'deki ip adresiyle karşılaştırılarak kontrol . ipAddress /collect edilmelidir Kimlik doğrulama akışının değiştirilemeyeceğinden emin olmak için ile birlikte sertifika politikaları . ipAddress KULLANILMALIDIR Bununla birlikte, bu güvenlik önlemleri mevcut olmasına rağmen BankID bunların önemini özetlemekte başarısız oluyor ve verilen örnek uygulamalarda bile bunları doğru şekilde uygulamıyor! https://github.com/BankID/SampleCode Oturum Sabitleme Hatası Peki bu protokol güvenli bir şekilde uygulanmadığında ne olur? deep linkini ilk gördüğümde BankID ile giriş yaparak ulaşabileceğim üniversite başvuru formlarıma göz atıyordum. İlk başta şunu düşündüm: Bu derin bağlantıyı birine gönderirsem ne olur? Ben de onu tıklayan bir arkadaşıma gönderdim ve BankID'yi açtıktan sonra sürpriz bir şekilde tüm üniversite başvuruları önümdeydi! bankid:/// İşte o zaman BankID'nin API'sini araştırmaya başladım, kendi RP'mi uyguladım ve az önce özetlediğim her şeyi öğrendim. Birkaç haftalık araştırmadan sonra, 30'dan fazla RP karşılığında Bu komut dosyası, bir kullanıcı bağlantıyı ziyaret ettiğinde bir web sunucusu başlatacak ve her hizmet için bir yol oluşturacaktı. belirli bir hizmette, komut dosyası yeni bir bağlantı getirir ve kullanıcıyı ona yönlendirir. Bu, kullanıcının cihazının BankID uygulamasını açmasına neden olur ve kimlik doğrulama sonrasında onlar yerine benim kimliğim doğrulanır. bankid:/// Bunu yapabildim çünkü: RP'ler sertifika politikalarını BankID'ye göndermedi, bu da benim derin bir bağlantı alıp bunu bir Mobile BankID uygulamasına aktarmamı mümkün kıldı RP'ler, bağlantıyı isteyen IP adresini, kimlik doğrulamayı tamamlayan IP adresiyle karşılaştırmadı RP'ler, "Başka bir cihazda kimlik doğrulaması yap" seçeneği seçildiğinde bile bağlantıyı sağladı Bu da Oturum Sabitleme güvenlik açığına yol açtı. Saldırı AmazingSevice AB adında savunmasız bir hizmet hayal edelim, sağlanan örnek kodu takip ederek BankID akışını uyguladılar ve bu uygulamayı adresinde barındırıyorlar. https://amazingservice.se/login/bankid Bir tehdit aktörü, AmazingSevice AB'de depolanan kullanıcı verileriyle ilgileniyor ve kurbanını göz önünde bulunduruyor. bağlantısını ele geçirme işlemini otomatikleştirmesi, bunu kendi sunucusunda barındırması ve ardından bağlantıyı kötü amaçlı sunucusuna kurbanlarına göndermesi yeterliydi. Kimlik avı dağıtımını (SMS, e-posta, vb.) seçtikten sonra, bağlantıyı mesaja AmazingSevice AB gibi davranarak yerleştirecek ve kurbandan oturum açmasını isteyecek. bankid:/// Böyle bir hesap ele geçirme işlemi çok az sosyal mühendislik gerektirir çünkü kurban bağlantıya tıkladığında hemen BankID'yi açması istenir ve saldırganın sitesinin "bilinmeyen bölgesini" çok daha tanıdık bir arayüz olan BankID'ye bırakır. Ayrıca mağdurun BankID uygulamasında göreceği kimlik doğrulama talebi AmazingSevice AB tarafından talep ediliyor ve bu da dolandırıcılık davranışlarının tespit edilmesini imkansız hale getiriyor. Mağdur kimlik doğrulaması yaptıktan sonra saldırganın oturumu, kurbanın hesabında doğrulanır ve kurban, BankID'de bulunan açığından yararlanılarak saldırganın parametresini olarak belirlemesine olanak tanıyarak daha da kandırılabilir. . Bu, kurbanın meşru hizmet web sitesine yönlendirilmesine ve kimlik doğrulamanın başarılı olmadığını düşünmesine neden olacaktır. Açık Yönlendirme güvenlik redirect https://amazingservice.se/login/bankid https://amazingservice.se/login/bankid Demo . Burada saldırıyı eylem halinde gösteren küçük bir video demosu var Bildirdiğim şirketlerden birini bariz nedenlerden dolayı kullanamadım, bunun yerine demo, BankID'nin demo hizmetinin buna karşı savunmasız olduğunu gösteriyor! Sağ köşede bağlantıyı alan kurbanın görüntüsü yer alıyor, burada saldırganın web sitesi ziyaret edilerek simüle ediliyor. Kurban bağlantıyı ziyaret ettiğinde, saldırganın sunucusu başsız tarayıcıyı açar ve daha sonra kurbanın telefonuna aktarılan bağlantısını çıkarır. BankID'nin uygulamasında, BankID'nin demo sitesinin meşru kaynağı olan “Test av BankID”yi görebilirsiniz. Ayrıca videonun başında, kimlik doğrulama sırasında herhangi bir IP adresi kontrolünün yapılmadığını görmek için bir VPN açılır. Sonuçta saldırganın dizüstü bilgisayarında kurban (Johan Johansson) olarak oturum açtığını görmek mümkün. bankid:/// Darbe Oturum Sabitleme hatası, kimlik doğrulama sağlayıcısı olarak İsveç BankID'sini kullanan ve sertifika ilkelerini ve kontrollerini yanlış (veya hiç uygulamamış) uygulayan herhangi bir uygulamada neden olur. Bu oldukça ciddi bir durum çünkü çoğu zaman kullanıcılarının kimliğini doğrulamak için BankID'yi kullanan hizmetler oldukça hassas verilere ve eylemlere erişime sahip oluyor. uygulamanın bu saldırıya karşı savunmasız olduğu tespit edildi ve mümkün olduğu kadar çok uygulamayla iletişime geçilerek büyük platformlarda 11 hata ödül raporunun kabul edilmesi sağlandı. ipAddress tek tıklamayla Hesap Devralmasına 30'dan fazla Bu güvenlik açığını bildirdiğim hizmetlerden biri, sorunun çok yaygın ve ciddi olması nedeniyle beni İsveç'in ulusal CSIRT'si ile temasa geçirmeyi başardı. Görüşmeler yeni başladı, eğer güncel bilgilerden haberdar olmak istiyorsanız beni Twitter'da (X) takip edin @m4st3rspl1nt3r İyileştirme Güvenli bir BankID RP API uygulamasının nasıl göründüğüne dair bir örnek arıyorsanız, Golang kitaplığı olarak kullanabileceğiniz veya mikro hizmet olarak özelleştirip dağıtabileceğiniz bir örnek oluşturdum. Onu bulabilirsin . burada BankID'nin Yanıtı Etkilenen hizmetlerin çoğu, özellikle de BBP'ler ve VDP'ler, raporuma oldukça anlayışlı ve hızlı bir şekilde yanıt verdi. Ancak BankID'nin yanıtı biraz farklıydı. Kendileriyle çeşitli kanallar aracılığıyla defalarca iletişime geçtikten sonra aldığım bir e-postada, sorunun farkında olduklarını ancak RP'ler için "entegrasyon kolaylığını" korumak adına bu konuda pek bir şey yapılamayacağını düşündüklerini açıkladılar. Ne yazık ki hala RP tarafında değişiklik yapılmasını gerektiren planlı hafifletme bana şu şekilde iletildi (ancak bazı nedenlerden dolayı belgelerinde hiçbir yerde bulunmuyor): RP'nin belirleyebileceği ek bir gereksinim Risk'tir. Bu işlem için kabul edilebilir risk seviyesini belirleyecektir. İşlemin riski gereken limitin üzerindeyse işlem bloke edilir "DÜŞÜK" - yalnızca düşük riskli emirleri kabul et "ORTA" - düşük ve orta riskli emirleri kabul et Bu ayarlandığında. Diğer hususların yanı sıra, RP tarafından sağlanması durumunda IP kontrolünü kendi tarafımızda gerçekleştireceğiz. Sağlandığı takdirde riskin izleneceği diğer risk parametreleri, başvuran Etki Alanı, userAgent ve DeviceIdentifier'dır. Ayrıca Açık Yönlendirme güvenlik açığını düzeltmeye yönelik bir plan da mevcuttur. Bu konudaki , genellikle çok hassas kullanıcı bilgilerini korumak için kullanılan, bu kadar kritik ve son derece benimsenmiş bir kimlik doğrulama sağlayıcısı geliştirip işletiyorsanız, RP'lerin güvenli bir şekilde entegre olabilmesi için güvenlik mekanizmalarınızı doğru şekilde belgelemeniz gerektiğidir. İsteğe bağlı güvenlik özellikleri tamamen işe yaramaz, eğer bir geliştirici belirli özellikleri/parametreleri uygulamadan zamandan tasarruf edebilirse, olacak olan budur ve bunun için RP tarafını suçlayamayız. BankID, "entegrasyon kolaylığını" korumak için mümkün olduğunca çok sayıda dolandırıcılık önleme ve güvenlik özelliğini kendi tarafına taşımak için elinden geleni yapmalı, aynı zamanda RP'nin uygulaması gereken ek güvenlik özelliklerini de doğru şekilde belgelediğinden emin olmalıdır; değil zorunlu olduğuna dikkat edin. kişisel görüşüm isteğe bağlı Özel Şirket Kamu Tehlikesinde Blogun bu kısmı tamamen benim görüşümdür. Bana göre bu güvenlik açığı, bir ülkenin nüfusu için kritik öneme sahip bir sistemin tamamen özel bir şirket tarafından kontrol altına alınmasının tehlikelerini gösteren bir örnek. Bunun bir yazılım şirketindeki başka bir güvenlik açığından daha ciddi olduğuna inanmamın nedeni, BankID'nin fazla İsveçli tarafından kullanılan bir şey olması, bankanıza, sigorta sağlayıcınıza, elektrik sağlayıcınıza ve diğer hassas platformlara giriş yapmak için kullanılıyor olmasıdır. gerçek dünya sonuçları var. 8,5 milyondan Birisi Facebook'ta bir Hesap Devralma işlemi bulursa, bazı resimlerinizi kaybedebilirsiniz; eğer birisi ülkenizin eID sağlayıcısında (genellikle özel) bir güvenlik açığı bulursa, bunun birinin hayatındaki yansımaları hayal edilemez olabilir. Giderek daha fazla Avrupa ülkesi eID'leri benimsiyor ve AB önümüzdeki yıllarda kendi AB eID'lerini kullanıma sunmayı planlıyor (bununla ilgili daha fazla bilgiyi bulabilirsiniz). burada Umudum, düzenleyicilerin, e-Kimlik sağlayıcılarının tamamen kamu kurumları tarafından geliştirilip kontrol edilmesi için baskı yapmaları ve muhtemelen bu tür sistemlerin açık kaynaklı olması ve güvenlik kusurları açısından düzenli olarak denetlenmesi gerekliliğidir. Özel bir şirket tarafından geliştirilen bu kadar kritik yazılımları toplumumuzda nasıl güvenle kabul edebiliriz? Daha fazla araştırma Bu blog yazısının ana konusu BankID'ye yapılan Oturum Sabitleme saldırısı olsa da, diğer birçok kimlik doğrulama/tanımlama sağlayıcısının da aynı kusurla tasarlandığını gördüm. Kimlik doğrulama akışını tamamlamak için başka bir cihazın (genellikle cep telefonu) kullanılmasını gerektiren sağlayıcılarda yeni bir güvenlik açığı sınıfı bulunabilir. Araştırma devam ediyor ve yakında daha fazla bulgumu ve üzerinde çalıştığım, bu tür güvenlik açıklarını otomatikleştirmek ve istismar etmek için kullanılabilecek bir yayınlamayı umuyorum. Bir sonraki konu olan için bizi takip etmeye devam edin aracı Tasarım Yoluyla Oturum Sabitleme - Cihazlar Arası Kimlik Doğrulama Kabusları O zamana kadar gezegeni hackleyin!
