Huntress'in Baş Güvenlik Araştırmacısı Matt Kiely tarafından yazılmıştır.
Kimlik saldırılarının dönen, yankılanan çılgınlığını araştıracağımız bu yolculuğa benimle birlikte gelin. Bugün, çoğu kimlik sağlayıcısında kullanılan temel kimlik doğrulama şeması olan OAuth 2.0'ın farklı uygulamalarının nasıl tamamen farklı saldırı yüzeylerine sahip olabileceğine dair bir vaka çalışması sunuyorum.
Bugünkü örnek olay incelemesinin konuları, Silikon Vadisi'nin hemen dışında yer alan ve gelecek vaat eden iki hurda teknoloji mağazası: Microsoft ve Google. Belki onları duymuşsundur?
En sevdiğim kimlik saldırılarından biri olan Cihaz Kodu Kimlik Avının bu iki kimlik sağlayıcı arasında nasıl bir araya geldiğine bakalım. Bu blogun sonunda, sevgili okuyucu, OAuth 2.0 uygulamasının bu iki kimlik sağlayıcısı arasındaki karşılaştırmasını ve bunun, aşırı güçlü saldırının patlama yarıçapını nasıl doğrudan kolaylaştırdığını veya ortadan kaldırdığını takdir edeceksiniz.
Onunla inek olmaya hazır mısın? Hadi onunla inek olalım.
Cihaz Kodu Kimlik Avını anlamadan önce ilk etapta bu saldırının var olmasını sağlayan özelliği anlamamız gerekiyor. Söz konusu özelliğin uygulamadan bağımsız bir dökümüyle ve nasıl kullanıldığıyla başlayalım. Cihaz kodu akışını, diğer bir deyişle cihaz yetkilendirme iznini karşılamanın zamanı geldi!
Senin okumana gerek kalmaması için ben RFC'yi okudum. Yine de uyku yardımı arıyorsanız bunu tavsiye ederim.
Cihaz yetkilendirme yetkisi, klavye, web tarayıcısı veya benzeri geleneksel bir giriş mekanizmasına sahip olmayan, internete bağlı bir cihazın kimliğini doğrulamak istenen senaryolarda kullanılır. RFC bu girişi kısıtlı cihazları çağırır. Ortalama bir IoT yazıcınızı, akıllı TV'nizi, dokunmatik ekranlı Wi-Fi özellikli ekmek kızartma makinenizi veya internete bağlı ancak tam özellikli bir kullanıcı arayüzüne sahip olmayan başka herhangi bir cihazı hayal edelim.
Wifi özellikli ekmek kızartma makinenizin kimliğini bulut kiracınızda doğrulamak istiyorsanız (ve gerçekten bunu yapmanın heyecanını kim istemez ki?), elinizde bir sorun var. Kiracınızın giriş sayfasına ekmek kızartma makinenizden erişemez ve kullanıcı adınızı ve şifrenizi giremezsiniz. Ancak bu senaryoda ekmek kızartma makinenizin altı haneli kodu girebileceğiniz bir dokunmatik ekrana sahip olduğunu hayal edelim. Giriş sayfasına göz atamıyor ve kullanıcı adınızı ve şifrenizi yazamıyorsunuz, peki ekmek kızartma makinesinin kimliğini nasıl doğrulayabilirsiniz?
Cihaz kodu akışı şunları yapmanızı sağlar:
Bu, girişi kısıtlı cihazların kimliğinin doğrulanması sorununu etkili bir şekilde çözer. Ahh! Artık ekmek kızartma makinenizi kiracınızla birleştirebilirsiniz.
Bu son derece niş geliyorsa, bunun nedeni budur. OAuth'un bu özelliğinin dar bir uygulaması vardır ve belirli kullanıcı türleri tarafından yalnızca birkaç senaryoda kullanılır. Basitçe söylemek gerekirse, KOBİ'deki ortalama kullanıcınızın muhtemelen cihaz kodu akışını bilmesine gerek kalmayacaktır.
Eğer bilgisayar korsanları herhangi bir konuda iyiyse, o da cihaz kodu akışı gibi niş özellikleri bulmak ve bu tek seferlik kimlik doğrulama yöntemini ilk erişim vektörüne dönüştürmektir. O halde hadi cihaz kodlarıyla kimlik avı hakkında konuşalım!
2026'nın en büyük tehditlerini açığa çıkaran canlı bir demo için Huntress CEO'su Kyle Hanslovan'a katılın: sosyal mühendislik, tarayıcı kimlik bilgileri hırsızlığı ve MFA'yı atlatmak.
Bilgisayar korsanlarını çalışırken izleyin ve işletmenizi korumak için savunmaları öğrenin. Katılımcılar, güvenlik açıklarını ortaya çıkarmak ve ekibinizi eğitmek için Kimlik Güvenliği Değerlendirmemize ücretsiz erişim hakkına sahiptir.
Cihaz kod akışından yararlanılarak yapılan kimlik avı yeni bir şey değil. Dr. Nestori Syynimaa, Dirk-jan Mollema ve Lina Lau (@inversecos) dahil olmak üzere zamanımızın büyük kimlik araştırmacılarından bazıları konu hakkında zaten yazılar yazdı. Bir miktar sosyal mühendislik ustalığı uygulanarak, cihaz kod akışı, daha sonra saldırgan tarafından kurtarılabilecek bazı kaynaklara erişim belirteci oluşturmak için birlikte seçilebilir ve kötü niyetli olarak kullanılabilir.
İşte nasıl gidiyor:
Bu saldırıyı gerçekleştirmek için Azure cihaz kod akışının kullanıldığı somut bir örneğe bakalım.
Saldırgan öncelikle cihaz kodunu ister. Bu, Azure cihaz kod akışı API'sinin cURL'sini oluşturmak kadar basittir. Unutmayın: Bir saldırgan olarak bunu yapabilirim. Kim olduğumu doğrulamam veya kanıtlamam gerekmiyor. İsteği doğru yapılandırdığım sürece API, süreci başlatmak için bir cihaz kodu verecek. cURL isteği şuna benzer:
…Neresi:
cURL isteği doğru biçimlendirilmişse API, cihaz kodunu, kullanıcı kodunu ve bunların nasıl kullanılacağına ilişkin bazı yararlı talimatları içeren bir JSON blobuyla yanıt verir:
Bu noktada, meşru bir cihaz kodu kimlik doğrulama senaryosunda kullanıcı, girişi kısıtlı bu cihazdan web tarayıcısı olan bir bilgisayara geçecek, https://microsoft.com/devicelogin adresine göz atacak ve web tarayıcısını kullanarak oturum açacaktır. Ancak saldırı senaryosunda saldırgan, kullanıcıya aynı cihaz kodu giriş sayfasına gitmesi, oturum açması ve daha fazla talimat beklemesi talimatını veren ikna edici bir kimlik avı oluşturur.
Saldırganın ikna edici bir bahaneyle bu kimlik avını gönderdiğini, dolayısıyla kurbanın https://microsoft.com/devicelogin adresine göz atarak sağlanan kodu girdiğini ve güvenilmeyen kaynaklardan kod girilmesine ilişkin uyarıyı gerektiği gibi görmezden geldiğini varsayalım.
Sayfa daha sonra kurbandan bir kullanıcı adı ve şifre istiyor…
… ve kurbanın zorunlu kıldığı MFA kontrolüne geçiyoruz…
Sayfa daha sonra kurbanın Microsoft Office'te oturum açmaya çalışıp çalışmadığını soran son bir soru veriyor; kullanıcı bunun rutin olduğunu varsayıyor ve tıklamalar devam ediyor…
Ve son olarak mağdur şunu görüyor (Şekil 9):
Tabii ki, eğer bu saldırıya kurban giden sizseniz, bu son derece kafa karıştırıcı olur.
Bu arada başka bir yerde saldırgan, Azure kimlik doğrulama API'sini yoklamak için başka bir cURL komutu oluşturur:
…Neresi:
Kullanıcı kimlik avının kurbanı olduğunda, kimlik doğrulaması artık OAuth belirteç API uç noktasında yaşayan ve doğru cihaz kodu sağlanarak alınabilecek bir dizi belirteç oluşturur. Saldırgan elbette cihaz kodunu biliyor çünkü bu, cihaz kodu oturum açma API'sine yapılan ilk cURL isteği tarafından oluşturuldu. Bu kod tek başına işe yaramaz olsa da, kurban kimlik doğrulaması için kandırıldığında ortaya çıkan jetonlar artık orijinal istekte hangi cihaz kodunun kullanıldığını bilen herkese ait oluyor.
Başarılı bir saldırı, saldırganın, kimlik avı yapılan kurban için etkili olan bir erişim jetonu ve bir yenileme jetonu kazanmasıyla sonuçlanır. Belirteçler, talep edilen bir kaynak (bu durumda Graph API) için etkilidir ve saldırganın, kimlik avı kurbanıymış gibi kaynaklara erişmesine olanak tanıyan bir dizi OAuth izinlerini kapsar. Saldırı tamamlandı, ilk erişim sağlandı, siber suçlular mutlu!
Bu saldırıyı sinsi yapan birkaç şey var.
İlk olarak bu saldırı, bazı güvenlik açıklarından veya hatalardan yararlanmak yerine meşru kimlik doğrulama akışını kullanıyor. Kimlik avı bağlamının tamamı, meşru (ele geçirilmemişse) cihaz kodu kimlik doğrulama akışını gerçekleştirmek için meşru Microsoft API'lerini kullanarak meşru Microsoft altyapısında kalır. Bu saldırı sırasında, birisinin cihaz kodu akışını kullanmaması gerektiği halde kullanması için kandırılması dışında gerçek bir istismar söz konusu değildir.
İkincisi, meşru kimlik doğrulama işlevinin kullanılmasıyla ilgili önceki nokta nedeniyle, saldırgan, kimlik avı kısmı sırasında meşru URL'leri kullanır. Güvenlik Farkındalığı Eğitimi almış bir kullanıcı, bağlantılardan haklı olarak şüphelendiğini biliyor olabilir, ancak URL olarak https://microsoft.com/devicelogin adresini gördüğünde gardını düşürebilir. Bu blogun metninde bu URL'yi değiştirmemin bir nedeni yok; bu siteyi ziyaret etmek %100 tamamen meşru, zararsız ve güvenlidir. Yukarıda belgelenen örneğin tamamı boyunca, kurbanı bir kez olsun yarım yamalak bir siteye göndermek ve kimlik bilgilerini girmek zorunda kalmadım. Saldırgan olarak kimlik avı saldırınız için meşru bir Microsoft URL'si kullanmanın ne kadar güçlü olacağını bir düşünün.
Son olarak (ve en önemlisi), saldırgan, bu saldırı nedeniyle oluşturulan belirli kaynak ve jeton türünü kontrol eder. Yukarıdaki örnekte saldırgan, kapsamı Graph API'ye ayarlanmış bir cihaz kodu oluşturur ve bir istemci kimliğini belirtir. Daha sonra önemli olacağı için müşteri kimliğini hatırlamanızı söylediğimi hatırlıyor musunuz? Kuyu…
Yukarıdaki örnekteki müşteri kimliği rastgele bir karakter dizisi değildir. Aslında Microsoft'un OAuth uygulaması, kimlik doğrulama akışları sırasında herkesin serbestçe kullanabileceği belgelenmemiş bir dizi istemci kimliği içerir. Buna İstemci Kimlikleri Ailesi adı veriliyor ve yakın zamanda Secureworks araştırmacıları tarafından keşfedildi. Bu konu oldukça karmaşık ancak kısaca özetlemek gerekirse: Client ID ile talep edilen kaynağın birleşimi, farklı şeylere kapsamı belirlenebilen bir token oluşturur.
Örneğin, yukarıdaki örnekte kullanılan istemci kimliği Microsoft Office istemcisine karşılık gelir. Graph API için belirteç oluşturulduğunda, ortaya çıkan belirteç, Graph API'yi çağırmak ve kullanıcının e-postalarını okumak, takvimine bakmak, dosyalarını okumak ve belirtecin kapsamında belirtilen diğer birçok şey için kullanılabilir:
İstemci Kimlikleri Ailesi büyüleyici olsa da büyük ölçüde bu blog yazısının kapsamı dışındadır. Ancak iki önemli sonuç şunlardır:
Kimlik doğrulama sırasında saldırganın kaynağı ve istemci kimliğini kontrol etmesine izin vermenin gücünü kısaca göstermek için, Dirk-jan'ın Birincil Yenileme Belirteçleri için Kimlik Avı hakkındaki blogundan başka bir yere bakmayın; burada bir saldırganın Birincil Yenileme Belirteci oluşturmak ve ilk erişim için onu çalmak için cihaz kodu kimlik avından nasıl yararlanabileceğini gösterir. Bu özellikle saldırganın cihaz kodu isteğinin kaynağını https://enrollment.manage.microsoft.com/ olarak ve istemci kimliğini Microsoft Kimlik Doğrulama Aracısı'na (29d9ed98-a469-4536-ade2-f981bc1d605e) olarak ayarlayabilmesi nedeniyle mümkündür. Bir kurbana bu parametrelerle başarılı bir şekilde kimlik avı yapılarak oluşturulan belirteç, Azure OAuth belirteç şemasındaki en güçlü belirteç türüdür.
Bu belirteç, diğer şeylerin yanı sıra, web kaynaklarında oturum açmak, hileli cihazları bir kiracıya birleştirmek, çok faktörlü kimlik doğrulama kayıtları oluşturmak ve çok daha fazlası için kullanılabilir. Bu, ülke çapındaki en güçlü tokendir ve saldırganın kontrolünden uzak, kimlik avı amaçlı küçük bir cihaz kodundan başka bir şey değildir!
(Bu arada, eğer kimlik araştırması ve kırmızı ekip oluşturmayla ilgileniyorsanız, Dirk-jan tarafından yayınlanan her blogu okuyun. Hayal kırıklığına uğramayacaksınız.)
Cihaz kodu kimlik avının Azure'da nasıl gerçekleştirildiğini ve bunun son derece güçlü olduğunu belirledik. Saldırgan, ortaya çıkan belirteçlerin belirli kaynak türü ve kapsamı üzerinde kontrol sahibi olur. Bu tamamen Microsoft ekosisteminde yaşayan bir saldırıdır. En kötü ihtimalle, var olan en güçlü token türünü çalmak için kullanılabilir.
Ancak cihaz kodu kimlik doğrulama akışının Azure'a özgü bir mekanizma olmadığını unutmayın. Bunun yerine Azure, bir kimlik doğrulama yöntemi olarak cihaz kodu akışını uygular. Cihaz kodu akışı spesifikasyonu OAuth 2.0 RFC'den gelir. Azure, cihaz kodu akışını uygulayan tek kimlik sağlayıcıdan çok uzaktır. O yüzden merak etmeden duramadım...
Bu, hangi kimlik sağlayıcıyı kullanırsanız kullanın, cihaz kodu kimlik avının da aynı derecede tehlikeli olduğu anlamına mı geliyor? Sadece böyle mi olacak?
Spoiler uyarısı! Cevap şaşırtıcı bir şekilde hayır. Ve uygulama ayrıntılarının bu tekniğin ne kadar zarar verebileceği üzerinde büyük bir etkiye sahip olduğu bir örneği görmek için iyi Google amcamızdan başka bir yere bakmamıza gerek yok.
Google'ı birincil kimlik sağlayıcısı olarak kullanan bir müşteriye karşı kırmızı takım anlaşmasında olduğumuzu varsayalım. Cihaz kodu kimlik avı saldırısını Google Workspace/Google Cloud API'lerini kullanarak yeniden oluşturmaya çalışalım. Her zaman olduğu gibi, geliştirici belgeleri başlamak için harika bir yerdir. Ve zorlu bir mücadeleye gireceğimiz hemen anlaşılıyor:
Belgelerde, tüm kapsamların cihaz kod akışı tarafından desteklenmediği açıkça belirtilmektedir. Ancak bilgisayar korsanları hiçbir zaman umudunu yitirmiyor; o halde gelin hangi kapsamların desteklendiğini inceleyelim:
OAuth 2.0 kapsamlarına ve bunların saldırganlar tarafından genel olarak kötüye kullanılmasına aşina iseniz sandalyenizden düşmüş olabilirsiniz. Bilmiyorsanız şu şekilde özetleyebilirim: İlk üç kapsam, OAuth 2.0 ve OpenID Connect'in (OIDC) tüm uygulamalarında evrenseldir ve varsa sınırlı kullanıma izin verir. Kullanım temellerini ararken, desteklenen kapsamların geri kalanı son derece dardır.
Şu anda benimle gerçekten gerçekçi olun - Azure'da, sonuçta elde edilen belirteçlerin temelde kurban kullanıcı olmanıza, sahte bir cihazı kurban kiracıya eklemenize, e-postalarında ve diğer kaynaklarda oturum açmanıza ve diğer inanılmaz derecede güçlü erişim türlerine izin verdiği bir cihaz kodu kimlik avı saldırısı oluşturabilirsiniz. Ve Google'da, GDrive dosya izin kapsamını şunu yapmak için kullanabiliriz: -notları kontrol eder- "yalnızca bu uygulamayla kullandığınız belirli Google Drive dosyalarını görmek, düzenlemek, oluşturmak ve silmek".
Daha saldırıya başlamadan önce Google'ın cihaz kodu akışını uygulaması, saldırı potansiyelini etkili bir şekilde etkisiz hale getirdi. Bunu okuyan herhangi bir kırmızı takım üyesi youtube.readonly kapsamını bir hesap devralma işlemine nasıl dönüştüreceğimi bana bildirmek isterse, kulaklarım var (şaka yapmıyorum, bana ulaşın: matt.kiely[at]huntresslabs.com ve konuşmak isterim). Ama nefesimi tutmuyorum.
Ama umut sonsuzdur, o yüzden yine de saldırıyı gerçekleştirmeye çalışalım. Bildiğim kadarıyla Google için Azure'da olduğu gibi genel istemci kimlikleri yok. Yani eğer saldırıyı gerçekleştirmek istiyorsak bir müşteri kimliğine ihtiyacımız var. İstemci kimliği almanın önerilen yolu, bir Google Workspace uygulaması oluşturmak ve onu OAuth 2.0'ı kullanacak şekilde yapılandırmaktır. Yani saldırıyı gerçekleştirirken bir miktar anonimlik umuyorsanız bunu pencereden dışarı atabilirsiniz.
Google'da bir OAuth uygulaması oluşturma zahmetine girseniz bile hâlâ başka kontroller ve güvenlik önlemleri mevcuttur. Örneğin, uygulamanız çok fazla güçlü izin gerektiriyorsa, herkesin kullanabilmesi için önce yayınlanması ve doğrulanması gerekir:
Ama bu bizim için sorun olmayacak, unuttun mu? Dört izin kapsamıyla sınırlıyız: GDrive için iki ve YouTube için iki. Burada tam olarak güçlü sömürü ilkelleriyle çalışmıyoruz.
Google'dan cihaz kodu istemeye yönelik teknik adımlar büyük ölçüde Azure'dakilerle aynıdır. Çeşitlilik sağlamak adına, ilk isteği gerçekleştirmek ve kimlik doğrulama tamamlanana kadar uç noktayı yoklamak için Python'u kullanacağız:
Betiği çalıştırdığımızda bize cihaz kodunu veriyor. Görünüşte kullanıcıya kimlik avı yapıyoruz ve onlara Azure cihaz kodu kimlik avı saldırısında olduğu gibi kimlik doğrulaması yapma talimatı veriyoruz:
Kurban kimlik bilgilerini girdiğinde, bir erişim jetonu ve yenileme jetonu alıyoruz! Ancak sınırlı kapsam göz önüne alındığında, ilk erişimi elde etmek için her ikisini de kullanırken iyi şanslar.
Önemli not: Azure ile karşılaştırıldığında Google ile saldırı yüzeyinin yalnızca yüzeyini çizdim. Burada belgelenmemiş istemci kimlikleri, istismara açık belgelenmemiş kapsamlar ve benim ve/veya topluluğun bilmediği diğer birçok olası saldırı vektörü bulunabilir. Ancak Google Cloud'daki saldırı vektörlerinin Azure eşdeğerleriyle karşılaştırıldığında önemli ölçüde daha sınırlı olduğunun zaten açıkça görüldüğünü düşünüyorum.
İki kimlik sağlayıcı arasında oldukça fark var!
Buradaki temel çıkarımı özetlemem gerekirse, şudur: Google, cihaz kod akışının özel bir alan olduğunu ve yalnızca belirli senaryolarda kullanıldığını anlar ve cihaz kod akışının kullanabileceği kapsamları buna göre sınırlar. Microsoft bu tür sınırlamalar yapmamaktadır.
Google'ın bunu neden bu şekilde uygulamayı seçtiğini tahmin edebilirsiniz. İki izin kümesinin GDrive ve YouTube ile ilgisi vardır. Google, muhtemelen cihaz kodu kimlik doğrulama akışını kullanacak istemci cihaz türlerinin akıllı TV'ler olduğunun farkındadır (belgeler bunu başlıkta bile belirtmektedir: "TV ve Sınırlı Girişli Cihaz Uygulamaları için OAuth 2.0"). Bir TV'ye erişim türlerinin eğlence odaklı olması gerektiğini hayal etmek zor değil - "hey akıllı TV, lütfen en sevdiğim YouTube videosunu oynat!"
Ancak bir dakikanızı ayırıp aynı OAuth özelliğinin iki uygulamasının her biriyle ilişkili olarak tamamen farklı saldırı yüzeylerine sahip olduğu gerçeğini anlayın. Azure'un talep edilen kapsamlar ve kaynaklar üzerinde kısıtlama bulunmaması, araştırmacıların cihaz kodu kimlik avı saldırıları için son derece güçlü saldırı temellerini belirlemesine yol açtı. Ancak Google'ın uygulaması aynı tür saldırılara ciddi kısıtlamalar getiriyor.
Diğer kimlik saldırılarının (izin verme saldırıları, hileli cihaz birleştirme vb.) Google'da Azure'da olduğu kadar etkili olup olmadığı belirsiz olsa da, cihaz kodu kimlik avının Google Cloud'da Azure'a göre çok daha az etkili olduğu sonucuna rahatlıkla varabiliriz.
Aynı özellik. Aynı tasarım. Farklı uygulamalar. Tamamen farklı saldırı yüzeyleri! Bu size şunu gösterecek: Tüm OAuth 2.0 uygulamaları eşit olsa da bazılarının diğerlerinden biraz daha eşit olduğu ortaya çıktı.
Canlı bir hackleme demosu için Huntress CEO'su ve eski NSA operatörü Kyle Hanslovan'a katılın. Bilgisayar korsanlarının dakikalar içinde kimlik bilgilerini nasıl çaldığını, MFA'yı nasıl atladığını ve sistemlerin güvenliğini nasıl aştığını izleyin. 2026'nın en önemli tehditleri hakkında bilgi edinin: sosyal mühendislik, tarayıcı kimlik bilgileri hırsızlığı ve birbirine bağlı sistem saldırıları.
Katılımcılar, güvenlik açıklarını ortaya çıkaran ve kendi bilgisayar korsanlığı demonuz için kurulum talimatları sağlayan Microsoft 365 için Kimlik Güvenliği Değerlendirmemize ücretsiz erişim hakkına sahiptir.
Savunmanızı güçlendirme ve modern siber suçluları zekanızla alt etme şansını kaçırmayın. Gelin, gölgeli olun, öğrenin ve günümüzün zanaatına meydan okumaya hazır olun!
Canlı Hack'e kaydolun
Huntress Labs tarafından desteklenmiş ve yazılmıştır.
Kaynak: Bleeping Computer