OCI Identity Domains açığı, User Manager'ların domain yöneticileri için API anahtarı oluşturabilmesine izin veriyordu

Ne yaşandı

Oracle Cloud Infrastructure'ın Identity Domains özelliğindeki bir açık, sınırlı yetkilere sahip bir User Manager rolüne sahip bir kullanıcının, bir Identity Domain Administrator'a ait bir API imzalama anahtarı oluşturabilmesine ve ardından OCI API'lerine o yönetici olarak kimlik doğrulaması yapabilmesine imkân tanıyordu — hedef kişinin parolasını bilmeye ya da hesabın MFA etmenlerine sahip olmaya gerek olmadan. Güvenlik şirketi NetSPI'den araştırmacı Scott Weston tarafından keşfedilen açıklık 13 Ekim 2026'da kamuya duyuruldu. dev.to üzerinde yayımlanan teknik bir analize göre Oracle, duyurudan birkaç ay önce, Haziran 2026'da bir düzeltme yayımlamıştı.\n Saldırı anonim erişim gerektirmiyordu ve yöneticinin hesabının önceden ele geçirilmiş olması da gerekmiyordu. Açık, güvenlik sınırı her işlemde uygulanmamış meşru bir yetki devrinden yararlanıyordu.

Tek bulutta iki yetkilendirme modeli

dev.to analizi, hatayı OCI içinde bir arada var olan iki yetkilendirme sisteminin çatışması olarak tanımlıyor. İlki, politikaların grupları kaynaklar üzerindeki eylemlere bağladığı klasik OCI IAM modeli. İkincisi ise kullanıcıları, grupları, uygulamaları ve idari rolleri — Identity Domain Administrator, User Administrator ve User Manager dahil — /admin/v1 üzerindeki SCIM tabanlı bir API ile yönetilen ayrı identity domain'leri içinde düzenleyen Identity Domains modeli.

İkisi net bir şekilde ayrılmış değil: OCI IAM politikalarıyla verilen izinler, Identity Domains API işlemlerinde de devreye girebiliyor. Bir diğer karışıklık noktası ise Default identity domain'in klasik OCI IAM API'siyle çalışması, buna karşılık varsayılan olmayan domain'lerin aynı türden kullanıcı işlemleri için SCIM API'sini gerektirmesidir.

Ayrıcalık yükseltmesi nasıl işledi

NetSPI, sınırı doğrudan test ederek başladı. Bir Identity Domain Administrator'ın hesabını değiştirme girişimleri — e-posta adresini veya parolayı değiştirme — engellendi; yani yetkilendirme modeli hassas profil işlemlerini koruyordu.

Ancak kimlik bilgileri farklı kurallara tabiydi. OCI API kimlik doğrulaması RSA imzalarına dayanıyor: kullanıcı bir private key saklar ve eşleşen public key'i Oracle'a kaydeder; bunun ardından istekler kayıtlı anahtar, parmak izi ve ilişkili OCI tanımlayıcıları kullanılarak doğrulanır. Kendi public key'ini bir yöneticinin hesabına ekleyebilen herhangi biri, private key'i ile istekleri imzalayabilir ve bu isteklerin yönetici tarafından yapılmış gibi kabul edilmesini sağlayabilir.

SCIM işlemi POST /admin/v1/ApiKeys tam olarak buna izin veriyordu. Bir User Manager, aynı rol o yöneticinin korumalı niteliklerine dokunamasa bile, sahibi olarak Identity Domain Administrator'ın hesabını gösteren bir API anahtarı oluşturabiliyordu. dev.to analizi, düşük yetkili hesabın kullanıcı yönetimi veren hiçbir OCI IAM politikasına sahip olmadığını vurguluyor; tüm saldırı yolu Identity Domain rolünün izinleri üzerinden işliyordu.

Daha geniş kimlik bilgisi yüzeyi ve kalıcılık

NetSPI ayrıca Auth Tokens ve SMTP kimlik bilgileri dahil diğer kimlik bilgisi türlerinin de benzer yollarla oluşturulabileceğini gözlemledi. Analizi bu bulguyu, hepsinin aynı şekilde kısıtlanmış veya yamalanmış olduğunu varsaymak yerine, bir kimliğe bağlı her kimlik doğrulama mekanizmasını incelemek için bir prompt olarak değerlendiriyor.

Teknik, MITRE ATT&CK T1098.001 (Additional Cloud Credentials) kapsamına denk geliyor. Ayrıca etkileşimli oturum denetimlerinin dokunmadığı bir kalıcılık da sağlıyor: bir API anahtarı web oturumunun süresi dolmuş olsa bile kullanılabilir durumda kalıyor ve yöneticinin parolası değiştirilse ya da konsolda MFA zorunlu kılınsa bile önceden kaydedilmiş bir anahtar otomatik olarak iptal edilmiyor.

Etkinin kapsamı

Bir Identity Domain Administrator, kendi domain'i içinde güçlüdür ama küresel bir tenancy yöneticisi değildir ve OCI altyapı kaynakları üzerinde kapsamlı haklara sahip olmayabilir. dev.to analizinin de belirttiği gibi, gerçek etki, ele geçirilen hesaba bağlı diğer politika ve izinlere bağlıdır.

Neden önemli

Çıkarılacak ders bu tek ürünle sınırlı değil. Açık, salt aşırı yetkili bir rolden ibaret değildi; bir kimlik bilgisi üzerindeki bir işlemin başka bir kimliğin neler yapabileceğini değiştirdiği noktada ortaya çıktı. Bir kullanıcıyı yönetmek, o kullanıcının teknik kimlik bilgilerini yönetmek ve kimliği doğrulanmış bir isteğin gerçekleştirebileceği eylemleri yetkilendirmek birbirinden ayrı üç denetimdir — ve ilkinin korunması ikincisini garanti etmez, üçüncüsü ise hedef kimliğin sahip olduğu her şeyi devralır. Ayrı ayrı tutarlı iki yetkilendirme modeli, tam da eşdeğer işlemleri düzenledikleri noktada bir ayrıcalık yükseltme yolu üretti.

Bulut güvenlik ekipleri için pratik çıkarım şu: bir yöneticinin etkileşimli girişini sağlamlaştırmak, aynı hesaba bağlı etkileşimli olmayan kimlik doğrulama yöntemleri hakkında hiçbir şey söylemez. Denetimler yalnızca kimin profilleri düzenleyebildiğini değil, kimin diğer kullanıcılar için kimlik bilgisi oluşturabildiğini de kapsamalıdır.