Ansible Tower / AWX / Automation controller Güvenliği

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Temel Bilgiler

Ansible Tower veya açık kaynak versiyonu AWX, Ansible’ın kullanıcı arayüzü, kontrol paneli ve REST API’si olarak da bilinir. Rol tabanlı erişim kontrolü, iş zamanlaması ve grafik envanter yönetimi ile Ansible altyapınızı modern bir UI’dan yönetebilirsiniz. Tower’ın REST API’si ve komut satırı arayüzü, mevcut araçlar ve iş akışlarına entegre etmeyi basit hale getirir.

Automation Controller, Ansible Tower’ın daha fazla yeteneğe sahip daha yeni bir versiyonudur.

Farklar

Bu kaynağa göre, Ansible Tower ile AWX arasındaki ana farklar alınan destek ve Ansible Tower’ın rol tabanlı erişim kontrolü, özel API’ler için destek ve kullanıcı tanımlı iş akışları gibi ek özelliklere sahip olmasıdır.

Teknoloji Yığını

  • Web Arayüzü: Kullanıcıların envanterleri, kimlik bilgilerini, şablonları ve işleri yönetebileceği grafik arayüzdür. Anlaşılır olması için tasarlanmıştır ve otomasyon işlerinizi anlamaya yardımcı olacak görselleştirmeler sağlar.
  • REST API: Web arayüzünde yapabileceğiniz her şeyi REST API aracılığıyla da yapabilirsiniz. Bu, AWX/Tower’ı diğer sistemlerle entegre etmenizi veya arayüzde genellikle gerçekleştireceğiniz eylemleri betik haline getirmenizi sağlar.
  • Veritabanı: AWX/Tower, yapılandırmasını, iş sonuçlarını ve diğer gerekli operasyonel verileri depolamak için bir veritabanı (genellikle PostgreSQL) kullanır.
  • RabbitMQ: Bu, AWX/Tower’ın farklı bileşenler arasında, özellikle web hizmeti ile görev çalıştırıcıları arasında iletişim kurmak için kullandığı mesajlaşma sistemidir.
  • Redis: Redis, görev kuyruğu için bir önbellek ve arka uç olarak hizmet eder.

Mantıksal Bileşenler

  • Envanterler: Envanter, işlerin (Ansible playbook’ları) çalıştırılabileceği hostlar (veya düğümler) koleksiyonudur. AWX/Tower, envanterlerinizi tanımlamanıza ve gruplamanıza olanak tanır ve ayrıca AWS, Azure gibi diğer sistemlerden host listelerini alabilen dinamik envanterleri destekler.
  • Projeler: Bir proje, esasen bir versiyon kontrol sistemi (Git gibi) üzerinden kaynaklanan Ansible playbook’ları koleksiyonudur ve gerektiğinde en son playbook’ları çekmek için kullanılır.
  • Şablonlar: İş şablonları, belirli bir playbook’un nasıl çalıştırılacağını tanımlar, envanter, kimlik bilgileri ve iş için diğer parametreleri belirtir.
  • Kimlik Bilgileri: AWX/Tower, SSH anahtarları, şifreler ve API jetonları gibi gizli bilgileri yönetmek ve depolamak için güvenli bir yol sağlar. Bu kimlik bilgileri, playbook’ların çalıştığında gerekli erişime sahip olabilmesi için iş şablonlarıyla ilişkilendirilebilir.
  • Görev Motoru: Burası sihrin gerçekleştiği yerdir. Görev motoru, Ansible üzerine inşa edilmiştir ve playbook’ları çalıştırmaktan sorumludur. İşler, görev motoruna yönlendirilir ve ardından belirtilen envanter üzerinde belirtilen kimlik bilgileri kullanılarak Ansible playbook’ları çalıştırılır.
  • Zamanlayıcılar ve Geri Çağırmalar: Bunlar, AWX/Tower’da belirli zamanlarda çalıştırılmak üzere işlerin zamanlanmasına veya dış olaylar tarafından tetiklenmesine olanak tanıyan gelişmiş özelliklerdir.
  • Bildirimler: AWX/Tower, işlerin başarısına veya başarısızlığına dayalı olarak bildirimler gönderebilir. E-postalar, Slack mesajları, web kancaları gibi çeşitli bildirim yöntemlerini destekler.
  • Ansible Playbook’ları: Ansible playbook’ları, yapılandırma, dağıtım ve orkestrasyon araçlarıdır. Sistemlerin istenen durumunu otomatik, tekrarlanabilir bir şekilde tanımlar. YAML ile yazılmıştır ve playbook’lar, yapılandırmaları, görevleri ve yürütülmesi gereken adımları tanımlamak için Ansible’ın deklaratif otomasyon dilini kullanır.

İş Yürütme Akışı

  1. Kullanıcı Etkileşimi: Bir kullanıcı, AWX/Tower ile Web Arayüzü veya REST API aracılığıyla etkileşimde bulunabilir. Bu, AWX/Tower tarafından sunulan tüm işlevselliklere ön uç erişimi sağlar.
  2. İş Başlatma:
  • Kullanıcı, Web Arayüzü veya API aracılığıyla bir İş Şablonu temelinde bir iş başlatır.
  • İş Şablonu, Envanter, Proje (playbook’u içeren) ve Kimlik Bilgileri referanslarını içerir.
  • İş başlatıldığında, işin yürütülmesi için AWX/Tower arka ucuna bir istek gönderilir.
  1. İş Kuyruğa Alma:
  • RabbitMQ, web bileşeni ile görev çalıştırıcıları arasındaki mesajlaşmayı yönetir. Bir iş başlatıldığında, RabbitMQ kullanılarak görev motoruna bir mesaj gönderilir.
  • Redis, yürütülmeyi bekleyen kuyrukta olan işleri yöneten görev kuyruğu için arka uç olarak hizmet eder.
  1. İşin Yürütülmesi:
  • Görev Motoru, kuyrukta bekleyen işi alır. İlgili playbook, envanter ve kimlik bilgileri hakkında gerekli bilgileri Veritabanı’ndan alır.
  • İlgili Proje’den alınan Ansible playbook’unu kullanarak, Görev Motoru belirtilen Envanter düğümleri üzerinde sağlanan Kimlik Bilgileri ile playbook’u çalıştırır.
  • Playbook çalışırken, yürütme çıktısı (loglar, bilgiler vb.) Veritabanı’na kaydedilir.
  1. İş Sonuçları:
  • Playbook çalışmayı bitirdiğinde, sonuçlar (başarı, başarısızlık, loglar) Veritabanı’na kaydedilir.
  • Kullanıcılar, sonuçları Web Arayüzü aracılığıyla görüntüleyebilir veya REST API aracılığıyla sorgulayabilir.
  • İş sonuçlarına bağlı olarak, Bildirimler kullanıcıları veya dış sistemleri işin durumu hakkında bilgilendirmek için gönderilebilir. Bildirimler e-postalar, Slack mesajları, web kancaları vb. olabilir.
  1. Dış Sistem Entegrasyonu:
  • Envanterler, dış sistemlerden dinamik olarak kaynaklanabilir, bu da AWX/Tower’ın AWS, Azure, VMware gibi kaynaklardan hostları çekmesine olanak tanır.
  • Projeler (playbook’lar), versiyon kontrol sistemlerinden alınabilir, böylece iş yürütme sırasında güncel playbook’ların kullanılması sağlanır.
  • Zamanlayıcılar ve Geri Çağırmalar, diğer sistemler veya araçlarla entegrasyon için kullanılabilir, bu da AWX/Tower’ın dış tetikleyicilere yanıt vermesini veya işleri önceden belirlenmiş zamanlarda çalıştırmasını sağlar.

Test için AWX laboratuvarı oluşturma

Belgeleri takip ederek AWX’ı çalıştırmak için docker-compose kullanmak mümkündür:

git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version

cd awx

# Build
make docker-compose-build

# Run
make docker-compose

# Or to create a more complex env
MAIN_NODE_TYPE=control EXECUTION_NODE_COUNT=2 COMPOSE_TAG=devel make docker-compose

# Clean and build the UI
docker exec tools_awx_1 make clean-ui ui-devel

# Once migrations are completed and the UI is built, you can begin using AWX. The UI can be reached in your browser at https://localhost:8043/#/home, and the API can be found at https://localhost:8043/api/v2.

# Create an admin user
docker exec -ti tools_awx_1 awx-manage createsuperuser

# Load demo data
docker exec tools_awx_1 awx-manage create_preload_data

RBAC

Desteklenen roller

En yetkili rol Sistem Yöneticisi olarak adlandırılır. Bu role sahip olan herkes her şeyi değiştirebilir.

Bir beyaz kutu güvenliği incelemesi için, Sistem Denetçisi rolüne ihtiyacınız olacak, bu rol tüm sistem verilerini görüntülemenizi sağlar ancak herhangi bir değişiklik yapmanıza izin vermez. Diğer bir seçenek Organizasyon Denetçisi rolünü almak olacaktır, ancak diğerini almak daha iyi olur.

Mevcut rollerin ayrıntılı açıklamasını almak için genişletin
  1. Sistem Yöneticisi:
  • Bu, sistemdeki herhangi bir kaynağa erişim ve değiştirme izinlerine sahip süper kullanıcı rolüdür.
  • Tüm organizasyonları, takımları, projeleri, envanterleri, iş şablonlarını vb. yönetebilirler.
  1. Sistem Denetçisi:
  • Bu role sahip kullanıcılar tüm sistem verilerini görüntüleyebilir ancak herhangi bir değişiklik yapamazlar.
  • Bu rol, uyum ve denetim için tasarlanmıştır.
  1. Organizasyon Rolleri:
  • Admin: Organizasyonun kaynakları üzerinde tam kontrol.
  • Auditor: Organizasyonun kaynaklarına yalnızca görüntüleme erişimi.
  • Member: Belirli izinleri olmayan bir organizasyonda temel üyelik.
  • Execute: Organizasyon içinde iş şablonlarını çalıştırabilir.
  • Read: Organizasyonun kaynaklarını görüntüleyebilir.
  1. Proje Rolleri:
  • Admin: Projeyi yönetebilir ve değiştirebilir.
  • Use: Projeyi bir iş şablonunda kullanabilir.
  • Update: Projeyi SCM (kaynak kontrolü) kullanarak güncelleyebilir.
  1. Envanter Rolleri:
  • Admin: Envanteri yönetebilir ve değiştirebilir.
  • Ad Hoc: Envanter üzerinde ad hoc komutları çalıştırabilir.
  • Update: Envanter kaynağını güncelleyebilir.
  • Use: Envanteri bir iş şablonunda kullanabilir.
  • Read: Yalnızca görüntüleme erişimi.
  1. İş Şablonu Rolleri:
  • Admin: İş şablonunu yönetebilir ve değiştirebilir.
  • Execute: İşi çalıştırabilir.
  • Read: Yalnızca görüntüleme erişimi.
  1. Kimlik Bilgisi Rolleri:
  • Admin: Kimlik bilgilerini yönetebilir ve değiştirebilir.
  • Use: Kimlik bilgilerini iş şablonlarında veya diğer ilgili kaynaklarda kullanabilir.
  • Read: Yalnızca görüntüleme erişimi.
  1. Takım Rolleri:
  • Member: Takımın bir parçası ancak belirli izinleri yok.
  • Admin: Takımın üyelerini ve ilişkili kaynakları yönetebilir.
  1. İş Akışı Rolleri:
  • Admin: İş akışını yönetebilir ve değiştirebilir.
  • Execute: İş akışını çalıştırabilir.
  • Read: Yalnızca görüntüleme erişimi.

AnsibleHound ile Sayım & Saldırı Yolu Haritalama

AnsibleHound, salt okunur Ansible Tower/AWX/Automation Controller API token’ını analiz edilmek üzere BloodHound (veya BloodHound Enterprise) içinde kullanılmaya hazır bir izin grafiğine dönüştüren, Go dilinde yazılmış açık kaynaklı BloodHound OpenGraph toplayıcısıdır.

Bu neden faydalı?

  1. Tower/AWX REST API son derece zengindir ve örneğinizin bildiği her nesne ve RBAC ilişkisini açığa çıkarır.
  2. En düşük ayrıcalıkla (Read) token ile erişilebilen tüm kaynakları (organizasyonlar, envanterler, ana bilgisayarlar, kimlik bilgileri, projeler, iş şablonları, kullanıcılar, takımlar…) özyinelemeli olarak saymak mümkündür.
  3. Ham veriler BloodHound şemasına dönüştürüldüğünde, Active Directory değerlendirmelerinde çok popüler olan aynı saldırı yolu görselleştirme yeteneklerini elde edersiniz – ancak şimdi CI/CD mülkünüze yönlendirilmiştir.

Güvenlik ekipleri (ve saldırganlar!) bu nedenle:

  • Kimin neyin yöneticisi olabileceğini hızlıca anlayabilir.
  • Erişilebilir kimlik bilgilerini veya ana bilgisayarları tanımlayabilir.
  • Tam kontrol elde etmek için birden fazla “Read ➜ Use ➜ Execute ➜ Admin” kenarını zincirleyebilir.

Ön koşullar

  • HTTPS üzerinden erişilebilen Ansible Tower / AWX / Automation Controller.
  • Sadece Read kapsamına sahip bir kullanıcı API token’ı ( Kullanıcı Ayrıntıları → Tokenlar → Token Oluştur → kapsam = Read).
  • Toplayıcıyı derlemek için Go ≥ 1.20 (veya önceden derlenmiş ikili dosyaları kullanın).

Derleme ve Çalıştırma

# Compile the collector
cd collector
go build . -o build/ansiblehound

# Execute against the target instance
./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN"

İçsel olarak AnsibleHound, (en az) aşağıdaki uç noktalara karşı sayfalı GET istekleri gerçekleştirir ve her JSON nesnesinde döndürülen ilişkili bağlantıları otomatik olarak takip eder:

/api/v2/organizations/
/api/v2/inventories/
/api/v2/hosts/
/api/v2/job_templates/
/api/v2/projects/
/api/v2/credentials/
/api/v2/users/
/api/v2/teams/

Tüm toplanan sayfalar disk üzerinde tek bir JSON dosyasında birleştirilir (varsayılan: ansiblehound-output.json).

BloodHound Dönüşümü

Ham Tower verisi daha sonra BloodHound OpenGraph’e AT (Ansible Tower) ile başlayan özel düğümler kullanılarak dönüştürülür:

  • ATOrganization, ATInventory, ATHost, ATJobTemplate, ATProject, ATCredential, ATUser, ATTeam

Ve ilişkileri / ayrıcalıkları modelleyen kenarlar:

  • ATContains, ATUses, ATExecute, ATRead, ATAdmin

Sonuç doğrudan BloodHound’a aktarılabilir:

neo4j stop   # if BloodHound CE is running locally
bloodhound-import ansiblehound-output.json

İsteğe bağlı olarak, yeni düğüm türlerinin görsel olarak farklı olması için özel simgeler yükleyebilirsiniz:

python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"

Savunma ve Saldırı Dikkate Alınacak Hususlar

  • Bir Read token genellikle zararsız olarak kabul edilir ancak yine de tam topoloji ve her bir kimlik bilgisi meta verisini sızdırır. Bunu hassas olarak değerlendirin!
  • En az ayrıcalık ilkesini uygulayın ve kullanılmayan token’ları döndürün / iptal edin.
  • API’yi aşırı sıralama için izleyin (birden fazla ardışık GET isteği, yüksek sayfalama aktivitesi).
  • Bir saldırgan perspektifinden bu, CI/CD boru hattı içinde mükemmel bir ilk tutunma → ayrıcalık yükseltme tekniğidir.

Referanslar

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin