Ansible Tower / AWX / Automation controller Security

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθετε & εξασκηθείτε στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

Basic Information

Ansible Tower ή η ανοιχτού κώδικα έκδοσή του AWX είναι επίσης γνωστή ως διεπαφή χρήστη του Ansible, πίνακας ελέγχου και REST API. Με έλεγχο πρόσβασης βάσει ρόλων, προγραμματισμό εργασιών και γραφική διαχείριση αποθεμάτων, μπορείτε να διαχειριστείτε την υποδομή Ansible από μια σύγχρονη διεπαφή. Το REST API και η γραμμή εντολών του Tower διευκολύνουν την ενσωμάτωσή του σε τρέχοντα εργαλεία και ροές εργασίας.

Ο Automation Controller είναι μια νεότερη έκδοση του Ansible Tower με περισσότερες δυνατότητες.

Differences

Σύμφωνα με αυτό, οι κύριες διαφορές μεταξύ του Ansible Tower και του AWX είναι η υποστήριξη που λαμβάνουν και το Ansible Tower έχει επιπλέον χαρακτηριστικά όπως έλεγχο πρόσβασης βάσει ρόλων, υποστήριξη για προσαρμοσμένα APIs και ροές εργασίας που καθορίζονται από τον χρήστη.

Tech Stack

  • Web Interface: Αυτή είναι η γραφική διεπαφή όπου οι χρήστες μπορούν να διαχειρίζονται αποθέματα, διαπιστευτήρια, πρότυπα και εργασίες. Είναι σχεδιασμένη να είναι διαισθητική και παρέχει οπτικοποιήσεις για να βοηθήσει στην κατανόηση της κατάστασης και των αποτελεσμάτων των εργασιών αυτοματοποίησης σας.
  • REST API: Ό,τι μπορείτε να κάνετε στη γραφική διεπαφή, μπορείτε επίσης να το κάνετε μέσω του REST API. Αυτό σημαίνει ότι μπορείτε να ενσωματώσετε το AWX/Tower με άλλα συστήματα ή να αυτοματοποιήσετε ενέργειες που θα εκτελούσατε συνήθως στη διεπαφή.
  • Database: Το AWX/Tower χρησιμοποιεί μια βάση δεδομένων (συνήθως PostgreSQL) για να αποθηκεύει τη διαμόρφωσή του, τα αποτελέσματα εργασιών και άλλα απαραίτητα δεδομένα λειτουργίας.
  • RabbitMQ: Αυτό είναι το σύστημα μηνυμάτων που χρησιμοποιείται από το AWX/Tower για να επικοινωνεί μεταξύ των διαφόρων στοιχείων, ειδικά μεταξύ της διαδικτυακής υπηρεσίας και των εκτελεστών εργασιών.
  • Redis: Το Redis λειτουργεί ως cache και backend για την ουρά εργασιών.

Logical Components

  • Inventories: Ένα απόθεμα είναι μια συλλογή από hosts (ή κόμβους) κατά των οποίων μπορούν να εκτελούνται εργασίες (Ansible playbooks). Το AWX/Tower σας επιτρέπει να ορίσετε και να ομαδοποιήσετε τα αποθέματά σας και υποστηρίζει επίσης δυναμικά αποθέματα που μπορούν να ανακτούν λίστες hosts από άλλα συστήματα όπως AWS, Azure κ.λπ.
  • Projects: Ένα έργο είναι ουσιαστικά μια συλλογή Ansible playbooks που προέρχονται από ένα σύστημα ελέγχου εκδόσεων (όπως το Git) για να αντλούν τα πιο πρόσφατα playbooks όταν χρειάζεται.
  • Templates: Τα πρότυπα εργασιών καθορίζουν πώς θα εκτελείται ένα συγκεκριμένο playbook, προσδιορίζοντας το απόθεμα, τα διαπιστευτήρια και άλλες παραμέτρους για την εργασία.
  • Credentials: Το AWX/Tower παρέχει έναν ασφαλή τρόπο για να διαχειρίζεστε και να αποθηκεύετε μυστικά, όπως κλειδιά SSH, κωδικούς πρόσβασης και API tokens. Αυτά τα διαπιστευτήρια μπορούν να συσχετιστούν με πρότυπα εργασιών ώστε τα playbooks να έχουν την απαραίτητη πρόσβαση όταν εκτελούνται.
  • Task Engine: Εδώ συμβαίνει η μαγεία. Ο κινητήρας εργασιών βασίζεται στο Ansible και είναι υπεύθυνος για την εκτέλεση των playbooks. Οι εργασίες αποστέλλονται στον κινητήρα εργασιών, ο οποίος στη συνέχεια εκτελεί τα Ansible playbooks κατά του καθορισμένου αποθέματος χρησιμοποιώντας τα καθορισμένα διαπιστευτήρια.
  • Schedulers and Callbacks: Αυτές είναι προηγμένες δυνατότητες στο AWX/Tower που επιτρέπουν στις εργασίες να προγραμματίζονται να εκτελούνται σε συγκεκριμένες χρονικές στιγμές ή να ενεργοποιούνται από εξωτερικά γεγονότα.
  • Notifications: Το AWX/Tower μπορεί να στέλνει ειδοποιήσεις με βάση την επιτυχία ή την αποτυχία των εργασιών. Υποστηρίζει διάφορους τρόπους ειδοποιήσεων όπως emails, μηνύματα Slack, webhooks κ.λπ.
  • Ansible Playbooks: Τα Ansible playbooks είναι εργαλεία διαμόρφωσης, ανάπτυξης και ορχήστρωσης. Περιγράφουν την επιθυμητή κατάσταση των συστημάτων με έναν αυτοματοποιημένο, επαναλαμβανόμενο τρόπο. Γραμμένα σε YAML, τα playbooks χρησιμοποιούν τη δηλωτική γλώσσα αυτοματοποίησης του Ansible για να περιγράψουν διαμορφώσεις, εργασίες και βήματα που πρέπει να εκτελούνται.

Job Execution Flow

  1. User Interaction: Ένας χρήστης μπορεί να αλληλεπιδράσει με το AWX/Tower είτε μέσω της Web Interface είτε μέσω του REST API. Αυτές παρέχουν πρόσβαση front-end σε όλες τις λειτουργίες που προσφέρει το AWX/Tower.
  2. Job Initiation:
  • Ο χρήστης, μέσω της Web Interface ή API, ξεκινά μια εργασία με βάση ένα Job Template.
  • Το Job Template περιλαμβάνει αναφορές στο Inventory, Project (που περιέχει το playbook) και Credentials.
  • Κατά την έναρξη της εργασίας, αποστέλλεται ένα αίτημα στο backend του AWX/Tower για να προγραμματιστεί η εργασία για εκτέλεση.
  1. Job Queuing:
  • RabbitMQ διαχειρίζεται τη μηνυματοδότηση μεταξύ του διαδικτυακού στοιχείου και των εκτελεστών εργασιών. Μόλις ξεκινήσει μια εργασία, ένα μήνυμα αποστέλλεται στον κινητήρα εργασιών χρησιμοποιώντας το RabbitMQ.
  • Redis λειτουργεί ως backend για την ουρά εργασιών, διαχειριζόμενος τις προγραμματισμένες εργασίες που περιμένουν εκτέλεση.
  1. Job Execution:
  • Ο Task Engine παραλαμβάνει την προγραμματισμένη εργασία. Ανακτά τις απαραίτητες πληροφορίες από τη Database σχετικά με το σχετικό playbook της εργασίας, το απόθεμα και τα διαπιστευτήρια.
  • Χρησιμοποιώντας το ανακτηθέν Ansible playbook από το σχετικό Project, ο Task Engine εκτελεί το playbook κατά των καθορισμένων κόμβων Inventory χρησιμοποιώντας τα παρεχόμενα Credentials.
  • Καθώς εκτελείται το playbook, η έξοδος εκτέλεσής του (καταγραφές, γεγονότα κ.λπ.) καταγράφεται και αποθηκεύεται στη Database.
  1. Job Results:
  • Μόλις ολοκληρωθεί η εκτέλεση του playbook, τα αποτελέσματα (επιτυχία, αποτυχία, καταγραφές) αποθηκεύονται στη Database.
  • Οι χρήστες μπορούν στη συνέχεια να δουν τα αποτελέσματα μέσω της Web Interface ή να τα ερωτήσουν μέσω του REST API.
  • Με βάση τα αποτελέσματα των εργασιών, οι Notifications μπορούν να αποσταλούν για να ενημερώσουν τους χρήστες ή τα εξωτερικά συστήματα σχετικά με την κατάσταση της εργασίας. Οι ειδοποιήσεις μπορεί να είναι emails, μηνύματα Slack, webhooks κ.λπ.
  1. External Systems Integration:
  • Inventories μπορούν να προέρχονται δυναμικά από εξωτερικά συστήματα, επιτρέποντας στο AWX/Tower να αντλεί hosts από πηγές όπως AWS, Azure, VMware και άλλα.
  • Projects (playbooks) μπορούν να αντλούνται από συστήματα ελέγχου εκδόσεων, διασφαλίζοντας τη χρήση ενημερωμένων playbooks κατά την εκτέλεση εργασιών.
  • Schedulers and Callbacks μπορούν να χρησιμοποιηθούν για να ενσωματωθούν με άλλα συστήματα ή εργαλεία, κάνοντάς το AWX/Tower να αντιδρά σε εξωτερικά triggers ή να εκτελεί εργασίες σε προκαθορισμένες χρονικές στιγμές.

AWX lab creation for testing

Following the docs it’s possible to use docker-compose to run AWX:

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

Supported roles

Ο πιο προνομιούχος ρόλος ονομάζεται System Administrator. Οποιοσδήποτε με αυτόν τον ρόλο μπορεί να τροποποιήσει οτιδήποτε.

Από μια white box security ανασκόπηση, θα χρειαστείτε τον System Auditor role, ο οποίος επιτρέπει να δείτε όλα τα δεδομένα του συστήματος αλλά δεν μπορεί να κάνει καμία αλλαγή. Μια άλλη επιλογή θα ήταν να αποκτήσετε τον Organization Auditor role, αλλά θα ήταν καλύτερα να αποκτήσετε τον άλλο.

Expand this to get detailed description of available roles
  1. System Administrator:
  • Αυτός είναι ο ρόλος του superuser με άδειες πρόσβασης και τροποποίησης οποιουδήποτε πόρου στο σύστημα.
  • Μπορούν να διαχειρίζονται όλες τις οργανώσεις, ομάδες, έργα, αποθέματα, πρότυπα εργασιών κ.λπ.
  1. System Auditor:
  • Χρήστες με αυτόν τον ρόλο μπορούν να δουν όλα τα δεδομένα του συστήματος αλλά δεν μπορούν να κάνουν καμία αλλαγή.
  • Αυτός ο ρόλος έχει σχεδιαστεί για συμμόρφωση και εποπτεία.
  1. Organization Roles:
  • Admin: Πλήρης έλεγχος στους πόρους της οργάνωσης.
  • Auditor: Πρόσβαση μόνο για προβολή στους πόρους της οργάνωσης.
  • Member: Βασική συμμετοχή σε μια οργάνωση χωρίς συγκεκριμένα δικαιώματα.
  • Execute: Μπορεί να εκτελεί πρότυπα εργασιών εντός της οργάνωσης.
  • Read: Μπορεί να δει τους πόρους της οργάνωσης.
  1. Project Roles:
  • Admin: Μπορεί να διαχειρίζεται και να τροποποιεί το έργο.
  • Use: Μπορεί να χρησιμοποιεί το έργο σε ένα πρότυπο εργασίας.
  • Update: Μπορεί να ενημερώνει το έργο χρησιμοποιώντας SCM (source control).
  1. Inventory Roles:
  • Admin: Μπορεί να διαχειρίζεται και να τροποποιεί το απόθεμα.
  • Ad Hoc: Μπορεί να εκτελεί ad hoc εντολές στο απόθεμα.
  • Update: Μπορεί να ενημερώνει την πηγή του αποθέματος.
  • Use: Μπορεί να χρησιμοποιεί το απόθεμα σε ένα πρότυπο εργασίας.
  • Read: Πρόσβαση μόνο για προβολή.
  1. Job Template Roles:
  • Admin: Μπορεί να διαχειρίζεται και να τροποποιεί το πρότυπο εργασίας.
  • Execute: Μπορεί να εκτελεί την εργασία.
  • Read: Πρόσβαση μόνο για προβολή.
  1. Credential Roles:
  • Admin: Μπορεί να διαχειρίζεται και να τροποποιεί τα διαπιστευτήρια.
  • Use: Μπορεί να χρησιμοποιεί τα διαπιστευτήρια σε πρότυπα εργασιών ή άλλους σχετικούς πόρους.
  • Read: Πρόσβαση μόνο για προβολή.
  1. Team Roles:
  • Member: Μέλος της ομάδας αλλά χωρίς συγκεκριμένα δικαιώματα.
  • Admin: Μπορεί να διαχειρίζεται τα μέλη της ομάδας και τους σχετικούς πόρους.
  1. Workflow Roles:
  • Admin: Μπορεί να διαχειρίζεται και να τροποποιεί τη ροή εργασίας.
  • Execute: Μπορεί να εκτελεί τη ροή εργασίας.
  • Read: Πρόσβαση μόνο για προβολή.

Enumeration & Attack-Path Mapping with AnsibleHound

AnsibleHound είναι ένας ανοιχτού κώδικα συλλέκτης BloodHound OpenGraph γραμμένος σε Go που μετατρέπει ένα read-only Ansible Tower/AWX/Automation Controller API token σε ένα πλήρες γράφημα δικαιωμάτων έτοιμο προς ανάλυση μέσα στο BloodHound (ή BloodHound Enterprise).

Why is this useful?

  1. Το Tower/AWX REST API είναι εξαιρετικά πλούσιο και εκθέτει κάθε αντικείμενο και σχέση RBAC που γνωρίζει η εγκατάστασή σας.
  2. Ακόμα και με το χαμηλότερο προνόμιο (Read) token είναι δυνατόν να καταμετρηθούν αναδρομικά όλοι οι προσβάσιμοι πόροι (οργανώσεις, αποθέματα, hosts, διαπιστευτήρια, έργα, πρότυπα εργασιών, χρήστες, ομάδες…).
  3. Όταν τα ακατέργαστα δεδομένα μετατραπούν στο σχήμα BloodHound, αποκτάτε τις ίδιες δυνατότητες οπτικοποίησης attack-path που είναι τόσο δημοφιλείς σε αξιολογήσεις Active Directory – αλλά τώρα κατευθυνόμενες προς την CI/CD περιουσία σας.

Οι ομάδες ασφαλείας (και οι επιτιθέμενοι!) μπορούν επομένως:

  • Να κατανοήσουν γρήγορα ποιος μπορεί να γίνει admin του τι.
  • Να εντοπίσουν διαπιστευτήρια ή hosts που είναι προσβάσιμα από έναν μη προνομιούχο λογαριασμό.
  • Να συνδυάσουν πολλαπλές “Read ➜ Use ➜ Execute ➜ Admin” ακμές για να αποκτήσουν πλήρη έλεγχο πάνω στην εγκατάσταση Tower ή την υποκείμενη υποδομή.

Prerequisites

  • Ansible Tower / AWX / Automation Controller προσβάσιμο μέσω HTTPS.
  • Ένα token API χρήστη περιορισμένο σε Read μόνο (δημιουργημένο από User Details → Tokens → Create Token → scope = Read).
  • Go ≥ 1.20 για να συντάξετε τον συλλέκτη (ή να χρησιμοποιήσετε τα προ-κατασκευασμένα δυαδικά αρχεία).

Building & Running

# 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"

Εσωτερικά, το AnsibleHound εκτελεί σελιδοποιημένα GET αιτήματα κατά των (τουλάχιστον) παρακάτω τελικών σημείων και ακολουθεί αυτόματα τους related συνδέσμους που επιστρέφονται σε κάθε αντικείμενο JSON:

/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/

Όλες οι συλλεγμένες σελίδες συγχωνεύονται σε ένα μόνο αρχείο JSON στον δίσκο (προεπιλογή: ansiblehound-output.json).

Μετασχηματισμός BloodHound

Τα ακατέργαστα δεδομένα του Tower μετασχηματίζονται σε BloodHound OpenGraph χρησιμοποιώντας προσαρμοσμένους κόμβους που ξεκινούν με AT (Ansible Tower):

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

Και ακμές που μοντελοποιούν σχέσεις / προνόμια:

  • ATContains, ATUses, ATExecute, ATRead, ATAdmin

Το αποτέλεσμα μπορεί να εισαχθεί απευθείας στο BloodHound:

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

Προαιρετικά, μπορείτε να ανεβάσετε προσαρμοσμένα εικονίδια ώστε οι νέοι τύποι κόμβων να είναι οπτικά διακριτοί:

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

Αμυντικές & Επιθετικές Σκέψεις

  • Ένα Read token θεωρείται συνήθως ακίνδυνο αλλά ακόμα διαρρέει την πλήρη τοπολογία και όλα τα μεταδεδομένα διαπιστευτηρίων. Αντιμετωπίστε το ως ευαίσθητο!
  • Επιβάλετε ελάχιστο δικαίωμα και περιστρέψτε / ανακαλέστε τα μη χρησιμοποιούμενα tokens.
  • Παρακολουθήστε το API για υπερβολική αρίθμηση (πολλαπλά διαδοχικά GET αιτήματα, υψηλή δραστηριότητα σε σελίδες).
  • Από την οπτική γωνία ενός επιτιθέμενου, αυτή είναι μια τέλεια τεχνική αρχικής πρόσβασης → κλιμάκωσης δικαιωμάτων μέσα στην CI/CD pipeline.

Αναφορές

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθετε & εξασκηθείτε στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks