İsveç BankID'deki Kritik Güvenlik Açığı Kullanıcı Verilerini Açığa Çıkardı

İ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 numaranız (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.

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 endUserIp parametresini belirtmelidir, bu daha sonra raporda önemli olacaktır.

/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" }

• orderRef , RP'nin kimlik doğrulama durumunu kontrol etmek ve daha sonra ihtiyaç duyduğu kullanıcı bilgilerini o kişiden almak için /collect uç noktasına karşı kullanabileceği bir tanımlayıcıdır
• autoStartToken , RP tarafından tıklandığında BankID uygulamasını açacak ve kullanıcıdan kendi kimliğini doğrulamasını isteyecek derin bir bağlantı oluşturmak için kullanılan bir belirteçtir ( Bu gerçekten önemli olacaktır )

qrStartToken ve qrStartSecret aşağıda ele alınacaktır ancak yürütülen güvenlik araştırması açısından kesinlikle önemli değildir.

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 kimlik doğrulama gereksinimleri de dahil olmak üzere daha fazla parametre belirleyebilir.

Kimlik doğrulama gereksinimleri arasında, bu yazının odaklanacağı olanlara sertifika politikaları denir; bunlar, RP'nin, kullanıcı tarafından iki akıştan hangisinin seçildiği BankID ile iletişim kurmasına olanak tanır.

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 autoStartToken kullanır: bankid:///?autostarttoken=7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6&redirect=https://service.com/login . 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.

Bu akışı araştırırken, redirect parametresinin BankID tarafından doğrulanması olmadığından bir Açık Yönlendirme 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.

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 /collect uç noktasından sonraki çerçevenin verilerini alarak) qrStartToken ve qrStartSecret kullanır. başvuru.

Sertifika Politikaları

Bunlar, bir kimlik doğrulama emri başlatılırken RP tarafından belirtilmelidir GEREKLİdir ; 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.

Bunlara ek olarak, kimlik doğrulama tamamlandıktan sonra RP, BankID uygulamasını açmak için kullanılan ipAddress /collect 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 edilmelidir .

Kimlik doğrulama akışının değiştirilemeyeceğinden emin olmak için ipAddress ile birlikte sertifika politikaları 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?

bankid:/// 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!

İş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 bankid:/// 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.

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ı https://amazingservice.se/login/bankid adresinde barındırıyorlar.

Bir tehdit aktörü, AmazingSevice AB'de depolanan kullanıcı verileriyle ilgileniyor ve kurbanını göz önünde bulunduruyor. bankid:/// 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.

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çık Yönlendirme güvenlik açığından yararlanılarak saldırganın redirect parametresini https://amazingservice.se/login/bankid olarak belirlemesine olanak tanıyarak daha da kandırılabilir. https://amazingservice.se/login/bankid . 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.

Demo

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 bankid:/// 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.

Darbe

Oturum Sabitleme hatası, kimlik doğrulama sağlayıcısı olarak İsveç BankID'sini kullanan ve sertifika ilkelerini ve ipAddress kontrollerini yanlış (veya hiç uygulamamış) uygulayan herhangi bir uygulamada tek tıklamayla Hesap Devralmasına 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. 30'dan fazla 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ı.

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 burada bulabilirsin .

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 kişisel görüşüm , 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; isteğe bağlı değil zorunlu olduğuna dikkat edin.

Özel Şirket Kamu Tehlikesinde

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 8,5 milyondan 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.

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 burada bulabilirsiniz).

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 aracı yayınlamayı umuyorum. Bir sonraki konu olan Tasarım Yoluyla Oturum Sabitleme - Cihazlar Arası Kimlik Doğrulama Kabusları için bizi takip etmeye devam edin

O zamana kadar gezegeni hackleyin!