OAuth Onay Oltalaması: Şifrenizi de MFA'nızı da Atlatan Saldırı

Bazı hesap ele geçirme olaylarında çalınan hiçbir şey yoktur. Kimlik bilgisi toplanmamıştır, oturum çerezi yeniden kullanılmamıştır, MFA sorusu bir aracı üzerinden yansıtılmamıştır. Kullanıcı gerçek oturum açma sayfasını açar, gerçek şifresini yazar, gerçek ikinci faktörünü geçirir ve daha önce defalarca göz ardı ettiği onay ekranıyla birebir aynı düğmeye basar. Otuz saniye sonra başka biri, sizin kendi kimlik sağlayıcınız tarafından üretilmiş, o mailbox'a ve o sürücüye yetkili, aylarca geçerli bir yenileme belirtecine sahiptir.

Temel değerlendirme: onay oltalaması ve cihaz kodu oltalaması, OAuth kullanan bir oltalama tekniği değildir; hedefin değişmesidir. Son on yılda aldığınız her kontrol — MFA, passkey, sızdırılmış şifre engelleme, riske dayalı doğrulama, arada-adam (AiTM) tespiti — kimlik doğrulama katmanını korur. Bu saldırı yetkilendirme katmanında çalışır: kullanıcı kimliğini doğru biçimde ispatlamış ve ardından erişimi gönüllü olarak vermiştir. İkinci faktörünüz, kimlik sağlayıcınızın onaylamasına izin verdiği bir yetkiyi reddetmek için tasarlanmamıştır. Çözüm; onay kapısı, uygulama allow-listesi, belirteç ömrü kontrolü ve denetim günlüğü eşleştirmesidir — ve çoğu kiracıda bu dördünün neredeyse hiçbiri çalışmıyor.

Saldırgan Neden Katman Değiştirdi

Teknik değil, ekonomi değişti. Şifre oltalaması, MFA ile sıfıra doğru itilen bir hacim oyunudur. Onay yetkisi ise bire-bir çalışır: kurban başına daha fazla emek, başarılı başına çok daha yüksek değer ve çalınmış bir şifrenin sahip olmadığı bir kalıcılık. Bir şifre, fark edildiği anda bir saat içinde döndürülür. Kurbanın adına üretilmiş bir yenileme belirteci, şifre değişikliğinden ve yapılandırmaya bağlı olarak ikinci faktör yeniden kurulumundan sağ çıkan bir kalıcılık mekanizmasıdır.

Birincil iki akış

Onay ekranı oltalaması

Sıra kısa ve her adımı meşru.

1. Bir uygulama kaydedin. Başlıca bulut kimlik platformlarında bu kendi kendine yapılır ve neredeyse bedava görünür. Görünen ad, platformun yayıncı doğrulama katmanında kontrol edilir; o katman ücretli ve belge istediği için kaydedenlerin çoğu onu hiç satın almaz. Uygulamayı çok kiracılı işaretlerseniz, kurbanın organizasyonu bunu kendi kurumsal uygulama envanterinde ancak bir kullanıcı yetki verip service principal oluştuğunda görür.
2. Kapsam isteyin. "Temel profilini oku" değil. Önemli katalog şudur: postaları okuma, postaları gönderme, postaları okuma/yazma, dosya ve site okuma/yazma, dizin okuma, sohbet veya görüşme okuma — bir de offline_access. Tek tıkı kalıcı erişime çeviren parametre odur.
3. Bir bağlantı gönderin. Şema, host ve yol gerçek kimlik sağlayıcısına aittir. client_id, scope ve redirect_uri sorgu parametreleri saldırgana aittir. Kullanıcının gördüğü sayfayı sağlayıcının kendisi üretir. Sahte sayfa diye bir şey yoktur. Kullanıcıya öğretilen tüm sezgiler — adrese bak, kilit simgesine bak, tanımadığın bir yere şifreni yazma — bu akışta geçerlidir.
4. Onayı dosya açmaya dönüştüren bir bahane seçin. "Paylaşılmış çalışma kitabı bu uygulamada", "bordronuz İK portalında hazır", "sözleşmeyi imzalamak için girin", "toplantı kaydı tek tıkla", "proje panosuna erişimi onaylayın". Bahanenin tek işi Onayla düğmesini en doğal sonraki adım gibi göstermektir.
5. Kodu alıp belirteçleri bozdurun. Yönlendirme bir yetki kodu alır; saldırgan bunu gizli istemcide kendi client secret'ıyla, herkese açık istemcide hiçbir gizli anahtar olmadan belirteçle değiştirir.

Savunucuyu ilgilendiren ayrıntı: yönlendirme hedefinin ulaşılabilir bir altyapı olması gerekmez. Meşru bir domain'de açık yönlendirme, saldırganın kendi makinesinde bir dinleyici, ya da kodu tarayıcıda gösteren herkese açık bir istemci akışı tamamlar. Bilinmeyen yönlendirme domainlerini engellemek bir kontrol değildir.

Cihaz kodu oltalaması

Cihaz kodu akışı klavyesiz cihazlar için var: oyun konsolları, set-top box'lar, akıllı TV'ler, IoT panelleri, bazı CLI araçları. İstemci sağlayıcıdan bir kod ister, kısa bir insan kodu ve bir doğrulama adresi alır, sonra bir insan yetkilendirene kadar sorgulamaya devam eder.

1. Saldırgan akışı bunu destekleyen herhangi bir istemciye karşı başlatır. Henüz kurbanla etkileşim yok.
2. Sağlayıcı bir kullanıcı kodu ve doğrulama adresi döner. Kod, onu isteyen kişiye bağlı değildir. O adrese giriş yapıp o kodu giren herkes, bekleyen isteği yetkilendirmiş olur.
3. Saldırgan ikiliyi kurbanlara gönderir: "BT masası çok faktörlü doğrulamayı etkinleştirdi, bu bağlantıyı açıp kodu girerek cihaz kaydınızı tamamlayın", "erişiminiz devam etsin diye oturumunuzu onaylayın", "yöneticiniz belge paylaştı, cihazınızı doğrulayın". Artık çoğu sürümde hiçbir şey yazılmasın diye QR görseliyle.
4. Kurban gerçek doğrulama sayfasını açar, gerçek kimlik bilgileri ve gerçek ikinci faktörüyle giriş yapar, kodu girer.
5. Saldırganın sorgulayan istemcisi belirteçleri alır.

Kurban hiçbir zaman şifresini paylaşmaz. Bir oturum açmayı harcamıştır. Bu etkileşimde saldırıya benzeyen hiçbir gösterge yoktur — "kodunuzu kimseyle paylaşmayın" uyarısının başarısız olması da bundandır; kullanıcı kodunu paylaşmıyor, kodu gerçek Microsoft veya gerçek Google sayfasına giriyordu.

İkisinin birbirine karıştığı yerler

• Yerel hesap yardımcısı açılır pencereleri. Giriş, tarayıcı sekmesi yerine işletim sisteminin hesap yardımcılarından gelir; kullanıcının kontrol etmesi öğretilen adres çubuğu hiç yoktur. Pencere "Şu Uygulama ile devam et" der ve bunun güvenli olup olmadığına verecek yanıt normal bir kullanıcıda yoktur.
• QR artı cihaz kodu. Basılı veya e-postayla gelen bir QR kodu, doğrulama sayfası kodu doldurulmuş halde açar. Kopyala-yapıştır adımını, yani bahanenin garip geldiği tek adımı kaldırır.
• Onay yorgunluğu. Sürekli gelen zararsız istemler tıklamayı alışkanlığa çevirir. Ortak kullanılan kiosk'lerde, eğitim laboratuvarlarında ve ikinci el cihazlarda bu bilinçli yapılır.
• Eski yüzeyler. Akış, birkaç yıl önce sonlanmış bir cihaz programı için açılmış ve kapatılmamış olduğu için hâlâ etkindir; kiracılar kimlik doğrulama yöntemlerini yapılandırma değil satıcı varsayılanı gibi görmeye alışmıştır.

Belirteç Gerçekte Ne Satın Alıyor

İki dürüst kayıt. Birincisi, kapsamlar tavan belirler taban değil: kiracı geneli dosya yazma yetkisi alan bir uygulama zarar vermek için kütüphaneyi gezmesine gerek yok, bir dosya yeter. İkincisi, delege edilmiş ile uygulama izinleri ayrımı olayın çapını belirler. Delege izinler onaylayan kullanıcı gibi hareket eder; tek bir onay tek bir kimliği ve o kimliğin API üzerinden erişebildiklerini tehlikeye atar. Uygulama izinleri uygulama gibi hareket eder, kullanıcıyı tamamen atlar ve yalnızca yetkili bir yönetici tarafından verilebilir — kiracıyı tehlikeye atar. Sınıflandırmaya bu soruyla başlayın: bir kullanıcı mı "evet" dedi, yoksa bir yönetici mi?

Zaten Kullandığınız Tespitler Neden Sessiz Kalır

Derin sebep bir veri modeli varsayımı. Kimse "bir kullanıcı bir uygulamayı onayladı" için tespit yazmadı, çünkü on beş yıl boyunca bu olay satın alma demekti. Hacmi düşük, insan başlatmalı ve iş akışına uygun görünüyor. Aynı zamanda kimlik denetim akışındaki en yüksek sinyalli yazma.

İşe Yarayan Tespit: Farklı Uygulama, Farklı Kimlik

Yapısal iz şudur: kimlik doğrulayan ile belirteci alan uygulama farklı şeylerdir ve kullanıcının normal istemcisi zincirin hiçbir yerinde görünmez. Bunu alarma çevirmek üç eşleştirme gerektirir.

1. Cihaz kodu eşleştirmesi. Hedefi sağlayıcının kendi cihaz-kayıt uç noktası olan bir kimlik doğrulama olayını bulun; ardından farklı bir client id için belirteç üretildiğini görün. Oltalamada ikinci olay sıklıkla başka bir adres bloğundan, başka bir user-agent'la ya da user-agent hiç olmadan gelir — bir token uç noktasını sorgulayan düz HTTP kütüphanesi tarayıcı değildir. İlgili uygulamaya eşleşen etkileşimli bir giriş olmadan cihaz-doğrulama sayfasına "başarılı" giriş, yanlış pozitif değil, bir ipucudur.
2. Onayı bir varlık gibi sorgulayın. Uygulama-onay denetim kayıtlarını olay sonrası arşiv taraması olarak değil, kalıcı bir tespit varlığı olarak sorgulayın. Alarm görülecek alanlar: kim onay verdi, hangi client id, hangi kapsamlar, yayıncı doğrulanmış mı, service principal sizin kiracınızda mı yaratıldı yoksa başka bir tenant'tan mı ödünç.
3. Client id kardinalitesi. En ucuz ve en verimli av. Meşru SaaS entegrasyonları tek client id altında birçok kullanıcı tarafından kullanılır. Saldırganın uygulaması tipik olarak tam olarak bir kullanıcı tarafından kullanılır — ve kiracının tüm tarihinde bir kez görünür, sonra sonsuza dek düzenli API trafiği üretir. Tek kullanıcılı ve ömrü sıfır olmayan bir client id, yanlışlıkla tetiklenmesi zor bir anomalidir.

Ardından, tek başına onaydan çok daha yüksek güvenle çalışan sonraki işaretler: yeni bir onaydan dakikalar sonra oluşturulan gelen kutusu kuralı, yönlendirme hedefi ya da vekillik; mühendislik dışı bir kullanıcının yaptığı yeni uygulama kaydı; o kullanıcı için hiç etkileşimli giriş görmemiş bir adres bloğundan gelen belirteç yenilemeleri; başka işi olmayan bir istemcinin dizin okumaları.

Kısıtı açık söyleyelim: bazı platformlarda cihaz kodu kimlik doğrulama kaydı, belirteci alacak uygulamayı adıyla yazmaz. Zinciri yalnızca giriş günlüğünden her zaman yeniden kuramazsınız. Giriş olayı, yetkilendirme olayı ve belirteç üretim olayı eşleştirilmelidir — ve çoğu kiracının hiç kurmadığı eşleştirme tam olarak budur.

Müdahale: Sırası Cevabı Koruyan Adım

Sıra burada çoğu olaydan daha kritik, çünkü iki adım birbirinin kanıtını yok ediyor.

1. İptal etmeden önce onay ve belirteç üretim kayıtlarını dışa aktarın. İptal de aynı denetim akışına yazmadır. Önce iptal edip sonra toplarsanız, nelerin okunabilir olduğunu söyleyen kapsam listesini kaybedersiniz.
2. Oturumu değil yetkiyi iptal edin. Oturum iptali verilmiş erişim belirteçlerini geçersiz kılar; ilgili istemciye bağlı yenileme belirteci, uygulama onayı ya da OAuth izinleri iptal edilene kadar yaşar — hem kullanıcı bazında hem uygulama bazında. İkisini de yapın, sonra o client id'yi kiracı genelinde engelleyin.
3. Soruşturma sürerken hesabın yeniden onay vermesini engelli tutun. Uygulamayı bloke edip bir saat sonra mailbox'ı eski haline açmak, aynı saldırganın yeni bir client id ile geri girmesinin standart yoludur.
4. Mailbox'ı kapatmadan önce sonraki adımları arayın. Gelen kutusu kuralları, "yönlendir ve sakla", vekillikler, yeni uygulama kayıtları ve — kritik olan — diğer kullanıcılar tarafından verilmiş aynı client id.
5. Kiracıda client id taraması yapın. Onay oltalaması bir organizasyon içinde seyrek olarak tek kurbanlıktır; bahane genellikle bir dağıtım listesine, ortak mailbox'ın izleyicilerine ya da bir tedarikçi grubuna gider.
6. Aynı kullanıcının bir yansıtma sayfasıyla da karşılaştığına dair en küçük işaret varsa ikinci faktörü sıfırlayın. İki olayın aynı olduğunu varsaymayın; farklı olduğunu da varsaymayın. Onay yetkisi alabilen bir saldırgan genellikle aynı kullanıcıyı bir AiM sayfasına da çekebilir; altyapı gerektirmeyen yolu tercih eder, o kadar.

Sonucu Değiştiren Kontroller

Bir maddeyi, farkındalık programını finanse eden kişiye yüksek sesle söylemek gerekir. Onay oltalaması, "şüpheli bağlantılara tıklamayın" mesajının yapısal olarak başarısız olduğu vaktır: bağlantı şüpheli değildir ve sayfa sahte değildir. Eğitim adres çubuğunu öğretiyorsa, bu saldırının ihlal etmediği bir sinyali öğretiyordur. Kullanıcılara, kendilerinin denetleyemeyeceği bir kapsam kararını devretmeyin. "Postalarınızı okuyup göndersin" ifadesi teknik olarak dürüst, pratikte anlamsızdır; onay ekranının okunabilir olması bir ürün sorunu, kullanıcı hijyeni sorunu değildir.

Biri Sınamadan Siz Sınayın

Üç kontrol, her biri savunulabilir kanıt standardıyla.

• Yönetici olmayan biri yüksek etkili kapsamlara onay verebiliyor mu? İkinci bir kiracıda minimal bir herkese açık istemci kaydedin, postaları okuma ve offline_access isteyin, bağlantıyı test hesabına gönderin. Bulgu yapılandırma ekran görüntüsü değil, sonuçtur.
• Cihaz kodu akışı ayrıcalıklı kimlikler için erişilebilir mi? Akışı başlatın ve koşullu erişiminiz yetkilendirme adımını mı, belirteç adımını mı, yoksa ikisini de mi engelliyor doğrulayın. İkisi farklıdır ve çalışıyor görünen politika sıklıkla hiçbir şeyi durdurmaz.
• Onay, giriş ve belirteç kayıtlarınız SIEM'de birleşiyor mu ve bir alarm düşüyor mu? Onayı enjekte edin, tespit gecikmesini ölçün, bulanın bir kural mı insan mı olduğunu kaydedin. Sonradan sorgulanabilen bir günlük tespit değildir.

Kapsam sınırı önemlidir: kendi kiracınızda, kendi hesaplarınızla yapılan onay testleri yetkilidir. Kimlik sağlayıcısını ya da üçüncü taraf bir uygulamanın kayıt sürecini yoklamak yetkili değildir. Çalışmayı upstream'e saldırmak etrafında değil, kendi yapılandırmanız ve kendi telemetriniz etrafında planlayın.

Sıkça Sorulan Sorular

Çok faktörlü doğrulama onay oltalamasına hiç yardımcı olmuyor mu?

Yalnızca tasarlandığı kısımda yardımcı olur. MFA, onay ya da doğrulama sayfasına başkası olarak ulaşmanın maliyetini yükseltir; saldırgan hâlâ gerçek, kimliğini ispatlamış bir insanı kandırmak zorundadır. Ama o insanın neyi onaylayabileceğini kısıtlamaz. Kimlik saldırılarına karşı yanıt olarak MFA'ya dayanıyorsanız, doğru devam kontrolü hiçbir kullanıcının açamayacağı bir onay kapısı ve kapıdan geçen her şey için belirteç ömrü sınırıdır.

Bir tarayıcı ya da CSPM bunu mümkün kılan yanlış yapılandırmayı bulabilir mi?

Kısmen, ve kaçırdığı kısım tehlikeli olan kısımdır. Duruş araçları şunları iyi raporlar: kullanıcı onayı açık, uygulama kaydı tüm çalışanlara açık, cihaz kodu akışına izin var, doğrulanmamış yayıncı uygulamaları mevcut, bir yıldan eski bayat yetkiler var. Raporlayamayacağı şey, tespit zincirinizin gerçekten çalışıp çalışmadığıdır: yeni bir client id belirdiğinde alarm kullanışlı bir zaman penceresi içinde düşüyor mu. Bu bir emüle tespit çalışmasıdır, yapılandırma okuması değil — ve iyileştirme listesi ile cevap arasındaki farkı yaratan da budur.

Sınıflandırmada delege edilmiş ile uygulama izinleri arasındaki fark nedir?

Delege izinler onaylayan kullanıcı adına hareket eder; ele geçirme o kimliğin API üzerinden erişebildiğiyle sınırlıdır. Uygulama izinleri uygulamanın kendisi gibi hareket eder, kullanıcıyı tamamen atlar ve yalnızca ayrıcalıklı biri tarafından verilebilir. Bir onay kaydında kiracı postası üzerinde uygulama izni görüyorsanız, onayı kimin verdiğine bakmadan kiracı düzeyinde olay muamelesi yapın. Delege kapsamlar görüyorsanız soruşturmayı o kimlikle ve erişebildiği nesnelerle sınırlayıp aynı client id'nin başka yerde geçip geçmediğine bakın.

Cihaz kodu akışını tamamen kapatmalı mıyım?

Kurumunuzda kimsenin gerçekten konsol, set-top box, akıllı TV ya da klavyesiz bir panelden giriş yapmasına gerek yoksa, kiracı genelinde kapatın ve düşünmeyi bırakın. Çoğu organizasyon bunu yapamaz; birkaç yıl önceki bir cihaz programı satın alma alışkanlığını hâlâ besler. Sürdürülebilir versiyon, cihaz kodu kimlik doğrulama yöntemini ayrıcalıklı ve yönetici kimlikler için reddeden, küçük ihtiyaç grubuna açık bırakan ve o grubu takvime bağlı gözden geçiren bir koşullu erişim politikasıdır.

Passkey'e geçmek beni bundan korur mu?

Hayır — ve onay kontrolleri aynı anda eklenmezse passkey geçişi tabloyu kötüleştirebilir. Passkey, kimlik bilgisi oltalamasını ve çoğu yansıtma saldırısını çok zorlaştırır; bu da saldırganı hâlâ işe yarayan yola iter: passkey ile doğrulanmış kullanıcıdan bir uygulamayı onaylamasını istemek. Oltalamaya dirençli kimlik doğrulama, güvenilir bir onay kararının ön koşuludur; onun yerine geçen şey değil.

Sonraki Adım

Ölçülebilir soru şu: telemetriniz bir onay olayını bir belirteç üretimiyle birleştiriyor mu ve bir şey yanlış göründüğünde birine ulaşılıyor mu. Eresus Security bunu kırmızı takım faaliyetleri ve olay müdahale hazırlığı kapsamımız içinde test eder; kimlik saldırı yolları AI ajan güvenliği ve API güvenliği testi kapsamlarında uç uca ele alınır. Çalışma standardımız olan kanıt ölçütü için Eresus Guard sayfasına bakın, onay ve belirteç akışı değerlendirmesi kapsamını konuşmak için bize ulaşın.