Ansible Tower / AWX / Automatiseringsbeheerder Sekuriteit

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

• Kyk na die subscription plans!
• Sluit aan by die 💬 Discord group of die telegram group of volg ons op Twitter 🐦 @hacktricks_live.
• Deel hacking tricks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.

Basiese Inligting

Ansible Tower of sy oopbron weergawe AWX is ook bekend as Ansible se gebruikerskoppelvlak, dashboard, en REST API. Met rolgebaseerde toegangbeheer, werkskedulering, en grafiese inventarisbestuur, kan jy jou Ansible-infrastruktuur vanaf ’n moderne UI bestuur. Tower se REST API en opdraglyn koppelvlak maak dit eenvoudig om dit in huidige gereedskap en werksvloei te integreer.

Automatiseringsbeheerder is ’n nuwer weergawe van Ansible Tower met meer vermoëns.

Verskille

Volgens hierdie, is die hoofverskille tussen Ansible Tower en AWX die ontvangde ondersteuning en die Ansible Tower het addisionele funksies soos rolgebaseerde toegangbeheer, ondersteuning vir pasgemaakte API’s, en gebruikersgedefinieerde werksvloei.

Tegnologiesteke

• Web Koppelvlak: Dit is die grafiese koppelvlak waar gebruikers inventarisse, akrediteer, sjablone, en werksgeleenthede kan bestuur. Dit is ontwerp om intuïtief te wees en bied visualisasies om te help met die begrip van die toestand en resultate van jou automatiseringswerk.
• REST API: Alles wat jy in die web koppelvlak kan doen, kan jy ook via die REST API doen. Dit beteken jy kan AWX/Tower met ander stelsels integreer of aksies skryf wat jy tipies in die koppelvlak sou uitvoer.
• Databasis: AWX/Tower gebruik ’n databasis (tipies PostgreSQL) om sy konfigurasie, werksresultate, en ander nodige operasionele data te stoor.
• RabbitMQ: Dit is die boodskapstelsel wat deur AWX/Tower gebruik word om tussen die verskillende komponente te kommunikeer, veral tussen die webdiens en die taaklopers.
• Redis: Redis dien as ’n kas en ’n agtergrond vir die taaklyn.

Logiese Komponente

• Inventarisse: ’n Inventaris is ’n versameling van gasheers (of nodes) teenoor wie se werksgeleenthede (Ansible speelboeke) kan loop. AWX/Tower laat jou toe om jou inventarisse te definieer en te groepeer en ondersteun ook dinamiese inventarisse wat gasheerlis te kan haal van ander stelsels soos AWS, Azure, ens.
• Projekte: ’n Projek is in wese ’n versameling van Ansible speelboeke wat afkomstig is van ’n weergawebeheerstelsel (soos Git) om die nuutste speelboeke te trek wanneer nodig.
• Sjablone: Werk sjablone definieer hoe ’n spesifieke speelboek uitgevoer sal word, wat die inventaris, akrediteer, en ander parameters vir die werk spesifiseer.
• Akrediteer: AWX/Tower bied ’n veilige manier om geheime te bestuur en te stoor, soos SSH sleutels, wagwoorde, en API tokens. Hierdie akrediteer kan met werksjablone geassosieer word sodat speelboeke die nodige toegang het wanneer hulle loop.
• Taak Enjin: Dit is waar die magie gebeur. Die taak enjin is gebou op Ansible en is verantwoordelik vir die speelboeke uit te voer. Werksgeleenthede word na die taak enjin gestuur, wat dan die Ansible speelboeke teen die aangewese inventaris met die gespesifiseerde akrediteer uitvoer.
• Skeerders en Terugroepe: Dit is gevorderde funksies in AWX/Tower wat toelaat dat werksgeleenthede geskeduleer kan word om op spesifieke tye te loop of geaktiveer te word deur eksterne gebeurtenisse.
• Kennisgewings: AWX/Tower kan kennisgewings stuur gebaseer op die sukses of mislukking van werksgeleenthede. Dit ondersteun verskeie middele van kennisgewings soos e-pos, Slack boodskappe, webhooks, ens.
• Ansible Speelboeke: Ansible speelboeke is konfigurasie, ontplooiing, en orkestrasie gereedskap. Hulle beskryf die gewenste toestand van stelsels op ’n geoutomatiseerde, herhaalbare manier. Geskryf in YAML, gebruik speelboeke Ansible se verklarende outomatiseringstaal om konfigurasies, take, en stappe wat uitgevoer moet word te beskryf.

Werk Uitvoering Stroom

1. Gebruiker Interaksie: ’n gebruiker kan met AWX/Tower interaksie hê of deur die Web Koppelvlak of die REST API. Hierdie bied front-end toegang tot al die funksies wat deur AWX/Tower aangebied word.
2. Werk Inisiasie:

• Die gebruiker, via die Web Koppelvlak of API, inisieer ’n werk gebaseer op ’n Werk Sjabloon.
• Die Werk Sjabloon sluit verwysings in na die Inventaris, Projekt (wat die speelboek bevat), en Akrediteer.
• By werk inisiasie, word ’n versoek na die AWX/Tower agtergrond gestuur om die werk vir uitvoering te queue.

3. Werk Queuing:

• RabbitMQ hanteer die boodskappe tussen die webkomponent en die taaklopers. Sodra ’n werk geinisieer is, word ’n boodskap na die taak enjin gestuur met behulp van RabbitMQ.
• Redis dien as die agtergrond vir die taaklyn, wat gequeue werksgeleenthede wat wag vir uitvoering bestuur.

4. Werk Uitvoering:

• Die Taak Enjin neem die gequeue werk op. Dit haal die nodige inligting van die Databasis oor die werk se geassosieerde speelboek, inventaris, en akrediteer.
• Met die onttrokken Ansible speelboek van die geassosieerde Projekt, voer die Taak Enjin die speelboek teen die gespesifiseerde Inventaris nodes uit met die verskafde Akrediteer.
• Soos die speelboek loop, word sy uitvoeringsuitset (logs, feite, ens.) vasgevang en in die Databasis gestoor.

5. Werk Resultate:

• Sodra die speelboek klaar is met loop, word die resultate (sukses, mislukking, logs) in die Databasis gestoor.
• Gebruikers kan dan die resultate deur die Web Koppelvlak sien of dit via die REST API opvra.
• Gebaseer op werksuitkomste, kan Kennisgewings gestuur word om gebruikers of eksterne stelsels oor die werk se status in te lig. Kennisgewings kan e-posse, Slack boodskappe, webhooks, ens. wees.

6. Eksterne Stelsels Integrasie:

• Inventarisse kan dinamies van eksterne stelsels verkry word, wat AWX/Tower toelaat om gasheers van bronne soos AWS, Azure, VMware, en meer in te trek.
• Projekte (speelboeke) kan van weergawebeheerstelsels verkry word, wat die gebruik van op-datum speelboeke tydens werk uitvoering verseker.
• Skeerders en Terugroepe kan gebruik word om met ander stelsels of gereedskap te integreer, wat AWX/Tower laat reageer op eksterne triggers of werksgeleenthede op voorafbepaalde tye te laat loop.

AWX laboratoriumskepping vir toetsing

Volg die dokumentasie is dit moontlik om docker-compose te gebruik om AWX te loop:

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

Ondersteunde rolle

Die mees bevoorregte rol word Sisteem Administrateur genoem. Enigeen met hierdie rol kan enige iets wysig.

Vanuit ’n wit boks sekuriteit hersiening, sal jy die Sisteem Ouditeur rol benodig, wat toelaat om alle sisteemdata te bekyk maar geen veranderinge kan aanbring nie. ’n Ander opsie sou wees om die Organisasie Ouditeur rol te verkry, maar dit sou beter wees om die ander een te kry.

Enumerasie & Aanvalspad Kaartlegging met AnsibleHound

AnsibleHound is ’n oopbron BloodHound OpenGraph versameling geskryf in Go wat ’n slegs lees Ansible Tower/AWX/Automatiseringsbeheer API-token in ’n volledige toestemmingsgrafiek omskakel wat gereed is om binne BloodHound (of BloodHound Enterprise) geanaliseer te word.

Waarom is dit nuttig?

1. Die Tower/AWX REST API is uiters ryk en stel elke objek en RBAC verhouding wat jou instansie ken, bloot.
2. Selfs met die laagste voorreg (Lees) token is dit moontlik om alle toeganklike hulpbronne (organisasies, inventarisse, gasheer, geloofsbriewe, projekte, werksjablone, gebruikers, spanne…) rekursief te enumerate.
3. Wanneer die rou data na die BloodHound skema omgeskakel word, verkry jy dieselfde aanvalspad visualisering vermoëns wat so gewild is in Aktiewe Gids assessments – maar nou gerig op jou CI/CD eiendom.

Sekuriteitspanne (en aanvallers!) kan dus:

• Vinnig verstaan wie admin van wat kan word.
• Identifiseer geloofsbriewe of gasheer wat bereik kan word vanaf ’n nie-bevoorregte rekening.
• Meerdere “Lees ➜ Gebruik ➜ Voer Uit ➜ Admin” kante ketting om volle beheer oor die Tower instansie of die onderliggende infrastruktuur te verkry.

Voorvereistes

• Ansible Tower / AWX / Automatiseringsbeheer bereikbaar oor HTTPS.
• ’n gebruiker API-token wat slegs op Lees geskaal is (gecreëer vanaf Gebruiker Besonderhede → Tokens → Token Skep → skaal = Lees).
• Go ≥ 1.20 om die versameling te kompileer (of gebruik die voorafgeboude binêre).

Bou & Loop

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

Intern intern AnsibleHound voer gepagineerde GET versoeke uit teen (ten minste) die volgende eindpunte en volg outomaties die verwante skakels wat in elke JSON-objek teruggestuur word:

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

Alle versamelde bladsye word in ’n enkele JSON-lêer op skyf saamgevoeg (verstek: ansiblehound-output.json).

BloodHound Transformasie

Die rou Tower-data word dan getransformeer na BloodHound OpenGraph met behulp van pasgemaakte knope wat met AT (Ansible Tower) voorafgegaan word:

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

En rande wat verhoudings / voorregte modelleer:

• ATContains, ATUses, ATExecute, ATRead, ATAdmin

Die resultaat kan regstreeks in BloodHound ingevoer word:

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

U kan pasgemaakte ikone opslaan sodat die nuwe knooppunt tipes visueel onderskeibaar is:

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

Verdedigende & Aanvallende Oorwegings

• ’n Read token word normaalweg as onskadelik beskou, maar lek steeds die volledige topologie en elke geloofsbrief metadata. Behandel dit as sensitief!
• Handhaaf minimale bevoegdheid en draai / herroep ongebruikte tokens.
• Monitor die API vir oormatige enumerasie (meervoudige opeenvolgende GET versoeke, hoë paginering aktiwiteit).
• Vanuit ’n aanvaller se perspektief is dit ’n perfekte beginpunt → bevoegdheid eskalasie tegniek binne die CI/CD pyplyn.

Verwysings

• AnsibleHound – BloodHound Collector for Ansible Tower/AWX
• BloodHound OSS

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

• Kyk na die subscription plans!
• Sluit aan by die 💬 Discord group of die telegram group of volg ons op Twitter 🐦 @hacktricks_live.
• Deel hacking tricks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.