Usalama wa Ansible Tower / AWX / Automation controller

Reading time: 10 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Taarifa za Msingi

Ansible Tower au toleo lake la wazi AWX pia linajulikana kama kiwango cha mtumiaji wa Ansible, dashibodi, na REST API. Pamoja na udhibiti wa ufikiaji kulingana na majukumu, kupanga kazi, na usimamizi wa hesabu wa picha, unaweza kusimamia miundombinu yako ya Ansible kutoka kwa UI ya kisasa. REST API ya Tower na kiolesura cha amri hufanya iwe rahisi kuunganisha na zana na mifumo ya kazi ya sasa.

Automation Controller ni toleo jipya la Ansible Tower lenye uwezo zaidi.

Tofauti

Kulingana na hii, tofauti kuu kati ya Ansible Tower na AWX ni msaada unaopatikana na Ansible Tower ina vipengele vya ziada kama udhibiti wa ufikiaji kulingana na majukumu, msaada wa APIs za kawaida, na mifumo ya kazi iliyofafanuliwa na mtumiaji.

Teknohali

  • Kiolesura cha Mtandao: Hii ni kiolesura cha picha ambapo watumiaji wanaweza kusimamia hesabu, ithibati, templeti, na kazi. Imeundwa kuwa ya kueleweka na inatoa picha kusaidia kuelewa hali na matokeo ya kazi zako za automatisering.
  • REST API: Kila kitu unachoweza kufanya katika kiolesura cha mtandao, unaweza pia kufanya kupitia REST API. Hii inamaanisha unaweza kuunganisha AWX/Tower na mifumo mingine au kuandika hatua ambazo ungeweza kufanya kawaida katika kiolesura.
  • Hifadhidata: AWX/Tower inatumia hifadhidata (kawaida PostgreSQL) kuhifadhi usanidi wake, matokeo ya kazi, na data nyingine muhimu za uendeshaji.
  • RabbitMQ: Hii ni mfumo wa ujumbe unaotumiwa na AWX/Tower kuwasiliana kati ya vipengele tofauti, hasa kati ya huduma ya mtandao na waendesha kazi.
  • Redis: Redis inatumika kama cache na nyuma ya foleni ya kazi.

Vipengele vya Kihisia

  • Hesabu: Hesabu ni mkusanyiko wa mwenyeji (au nodi) ambao kazi (Ansible playbooks) zinaweza kufanywa. AWX/Tower inakuruhusu kufafanua na kuunganisha hesabu zako na pia inasaidia hesabu za kidinamik ambazo zinaweza kupata orodha za wenyeji kutoka mifumo mingine kama AWS, Azure, n.k.
  • Miradi: Mradi kimsingi ni mkusanyiko wa Ansible playbooks zinazotolewa kutoka kwa mfumo wa udhibiti wa toleo (kama Git) ili kuvuta playbooks za hivi punde inapohitajika.
  • Templeti: Templeti za kazi zinafafanua jinsi playbook fulani itakavyofanywa, zikielezea hesabu, ithibati, na vigezo vingine vya kazi.
  • Ithibati: AWX/Tower inatoa njia salama ya kusimamia na kuhifadhi siri, kama funguo za SSH, nywila, na tokeni za API. Ithibati hizi zinaweza kuunganishwa na templeti za kazi ili playbooks zipate ufikiaji unaohitajika zinapofanywa.
  • Injini ya Kazi: Hapa ndipo uchawi unafanyika. Injini ya kazi imejengwa juu ya Ansible na inawajibika kwa kufanya playbooks. Kazi zinatumwa kwa injini ya kazi, ambayo kisha inafanya playbooks za Ansible dhidi ya hesabu iliyoteuliwa kwa kutumia ithibati zilizotolewa.
  • Wapangaji na Mkurugenzi: Hizi ni vipengele vya juu katika AWX/Tower vinavyoruhusu kazi kupanga kufanywa kwa nyakati maalum au kuanzishwa na matukio ya nje.
  • Arifa: AWX/Tower inaweza kutuma arifa kulingana na mafanikio au kushindwa kwa kazi. Inasaidia njia mbalimbali za arifa kama barua pepe, ujumbe wa Slack, webhooks, n.k.
  • Ansible Playbooks: Ansible playbooks ni zana za usanidi, uwekaji, na uratibu. Zinabainisha hali inayotakiwa ya mifumo kwa njia ya automatisering, inayoweza kurudiwa. Imeandikwa kwa YAML, playbooks hutumia lugha ya automatisering ya Ansible kuelezea usanidi, kazi, na hatua zinazohitajika kutekelezwa.

Mchakato wa Utekelezaji wa Kazi

  1. Mingiliano ya Mtumiaji: Mtumiaji anaweza kuingiliana na AWX/Tower ama kupitia Kiolesura cha Mtandao au REST API. Hizi zinatoa ufikiaji wa mbele kwa kazi zote zinazotolewa na AWX/Tower.
  2. Kuanza Kazi:
  • Mtumiaji, kupitia Kiolesura cha Mtandao au API, anaanzisha kazi kulingana na Templeti ya Kazi.
  • Templeti ya Kazi inajumuisha marejeleo kwa Hesabu, Mradi (unaoshikilia playbook), na Ithibati.
  • Mara kazi inapoanzishwa, ombi linawekwa kwa AWX/Tower backend ili kupanga kazi kwa utekelezaji.
  1. Kupanua Kazi:
  • RabbitMQ inashughulikia ujumbe kati ya kipengele cha mtandao na waendesha kazi. Mara kazi inapoanzishwa, ujumbe unatumwa kwa injini ya kazi kwa kutumia RabbitMQ.
  • Redis inafanya kazi kama nyuma ya foleni ya kazi, ikisimamia kazi zilizopangwa zinazosubiri utekelezaji.
  1. Utekelezaji wa Kazi:
  • Injini ya Kazi inachukua kazi iliyopangwa. Inapata taarifa muhimu kutoka kwa Hifadhidata kuhusu playbook inayohusiana na kazi, hesabu, na ithibati.
  • Kwa kutumia playbook ya Ansible iliyopatikana kutoka kwa Mradi uliohusika, Injini ya Kazi inafanya playbook dhidi ya nodi za Hesabu zilizotolewa kwa kutumia Ithibati zilizotolewa.
  • Wakati playbook inatekelezwa, matokeo yake ya utekelezaji (kumbukumbu, ukweli, n.k.) yanakamatwa na kuhifadhiwa katika Hifadhidata.
  1. Matokeo ya Kazi:
  • Mara playbook inapokamilisha utekelezaji, matokeo (mafanikio, kushindwa, kumbukumbu) yanahifadhiwa katika Hifadhidata.
  • Watumiaji wanaweza kisha kuona matokeo kupitia Kiolesura cha Mtandao au kuyatafuta kupitia REST API.
  • Kulingana na matokeo ya kazi, Arifa zinaweza kutumwa ili kuwajulisha watumiaji au mifumo ya nje kuhusu hali ya kazi. Arifa zinaweza kuwa barua pepe, ujumbe wa Slack, webhooks, n.k.
  1. Uunganisho wa Mifumo ya Nje:
  • Hesabu zinaweza kupatikana kwa kidinamik kutoka mifumo ya nje, kuruhusu AWX/Tower kuvuta wenyeji kutoka vyanzo kama AWS, Azure, VMware, na zaidi.
  • Miradi (playbooks) zinaweza kupatikana kutoka kwa mifumo ya udhibiti wa toleo, kuhakikisha matumizi ya playbooks za kisasa wakati wa utekelezaji wa kazi.
  • Wapangaji na Mkurugenzi wanaweza kutumika kuunganisha na mifumo au zana nyingine, na kufanya AWX/Tower ijibu kwa vichocheo vya nje au kufanya kazi kwa nyakati zilizopangwa.

Uundaji wa maabara ya AWX kwa majaribio

Kufuata nyaraka inawezekana kutumia docker-compose kuendesha AWX:

bash
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

Jukumu lenye mamlaka zaidi linaitwa System Administrator. Mtu yeyote mwenye jukumu hili anaweza kubadilisha chochote.

Kutoka kwenye white box security ukaguzi, unahitaji System Auditor role, ambayo inaruhusu kuangalia data zote za mfumo lakini haiwezi kufanya mabadiliko yoyote. Chaguo lingine lingekuwa kupata Organization Auditor role, lakini itakuwa bora kupata ile nyingine.

Expand this to get detailed description of available roles
  1. System Administrator:
  • Hii ni jukumu la superuser lenye ruhusa za kufikia na kubadilisha rasilimali yoyote katika mfumo.
  • Wanaweza kusimamia mashirika yote, timu, miradi, orodha, templeti za kazi, nk.
  1. System Auditor:
  • Watumiaji wenye jukumu hili wanaweza kuona data zote za mfumo lakini hawawezi kufanya mabadiliko yoyote.
  • Jukumu hili limetengwa kwa ajili ya ufuatiliaji na usimamizi.
  1. Organization Roles:
  • Admin: Udhibiti kamili juu ya rasilimali za shirika.
  • Auditor: Ufikiaji wa kuona tu wa rasilimali za shirika.
  • Member: Uanachama wa msingi katika shirika bila ruhusa maalum.
  • Execute: Anaweza kukimbia templeti za kazi ndani ya shirika.
  • Read: Anaweza kuona rasilimali za shirika.
  1. Project Roles:
  • Admin: Anaweza kusimamia na kubadilisha mradi.
  • Use: Anaweza kutumia mradi katika templeti ya kazi.
  • Update: Anaweza kuboresha mradi kwa kutumia SCM (source control).
  1. Inventory Roles:
  • Admin: Anaweza kusimamia na kubadilisha orodha.
  • Ad Hoc: Anaweza kukimbia amri za ad hoc kwenye orodha.
  • Update: Anaweza kuboresha chanzo cha orodha.
  • Use: Anaweza kutumia orodha katika templeti ya kazi.
  • Read: Ufikiaji wa kuona tu.
  1. Job Template Roles:
  • Admin: Anaweza kusimamia na kubadilisha templeti ya kazi.
  • Execute: Anaweza kukimbia kazi.
  • Read: Ufikiaji wa kuona tu.
  1. Credential Roles:
  • Admin: Anaweza kusimamia na kubadilisha akreditivu.
  • Use: Anaweza kutumia akreditivu katika templeti za kazi au rasilimali nyingine zinazohusiana.
  • Read: Ufikiaji wa kuona tu.
  1. Team Roles:
  • Member: Sehemu ya timu lakini bila ruhusa maalum.
  • Admin: Anaweza kusimamia wanachama wa timu na rasilimali zinazohusiana.
  1. Workflow Roles:
  • Admin: Anaweza kusimamia na kubadilisha mchakato.
  • Execute: Anaweza kukimbia mchakato.
  • Read: Ufikiaji wa kuona tu.

Enumeration & Attack-Path Mapping with AnsibleHound

AnsibleHound ni mkusanyiko wa BloodHound OpenGraph wa chanzo wazi ulioandikwa kwa Go ambao unageuza read-only Ansible Tower/AWX/Automation Controller API token kuwa grafu kamili ya ruhusa inayoweza kuchambuliwa ndani ya BloodHound (au BloodHound Enterprise).

Why is this useful?

  1. Tower/AWX REST API ina utajiri mkubwa na inafichua kila kitu na uhusiano wa RBAC ambacho mfano wako unajua.
  2. Hata na ruhusa ya chini zaidi (Read) token inawezekana kuhesabu kwa kurudi nyuma rasilimali zote zinazopatikana (mashirika, orodha, mwenyeji, akreditivu, miradi, templeti za kazi, watumiaji, timu…).
  3. Wakati data ghafi inabadilishwa kuwa muundo wa BloodHound unapata uwezo sawa wa attack-path wa kuona ambao ni maarufu katika tathmini za Active Directory – lakini sasa umeelekezwa kwenye mali zako za CI/CD.

Timu za usalama (na washambuliaji!) zinaweza hivyo:

  • Kuelewa haraka nani anaweza kuwa admin wa nini.
  • Kutambua akreditivu au wenyeji wanaoweza kufikiwa kutoka kwa akaunti isiyo na ruhusa.
  • Kuunganisha mipaka kadhaa “Read ➜ Use ➜ Execute ➜ Admin” ili kupata udhibiti kamili juu ya mfano wa Tower au miundombinu inayohusiana.

Prerequisites

  • Ansible Tower / AWX / Automation Controller inayopatikana kupitia HTTPS.
  • Token ya API ya mtumiaji iliyo na mipaka ya Read tu (iliyoundwa kutoka User Details → Tokens → Create Token → scope = Read).
  • Go ≥ 1.20 ili kukusanya mkusanyiko (au tumia binaries zilizojengwa tayari).

Building & Running

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

Ndani ya AnsibleHound inatekeleza paginated GET maombi dhidi ya (angalau) mwisho zifuatazo na moja kwa moja inafuata viungo related vinavyorejeshwa katika kila kitu cha 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/

All collected pages are merged into a single JSON file on disk (default: ansiblehound-output.json).

BloodHound Transformation

Data ghafi ya Tower kisha inabadilishwa kuwa BloodHound OpenGraph kwa kutumia nodi maalum zilizoanzishwa na AT (Ansible Tower):

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

Na edges zinazoonyesha uhusiano / haki:

  • ATContains, ATUses, ATExecute, ATRead, ATAdmin

Matokeo yanaweza kuingizwa moja kwa moja katika BloodHound:

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

Kwa hiari unaweza kupakia ikon za kawaida ili aina mpya za nodi ziwe tofauti kwa mtazamo:

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

Defensive & Offensive Considerations

  • A Read token kwa kawaida inachukuliwa kuwa haina madhara lakini bado inavuja topolojia kamili na metadata ya akreditivu zote. Treat it as sensitive!
  • Enforce least privilege na badilisha / futa tokens zisizotumika.
  • Monitor the API kwa uainishaji mwingi (maombi mengi ya mfululizo ya GET, shughuli kubwa ya pagination).
  • Kutoka kwa mtazamo wa mshambuliaji hii ni mbinu bora ya initial foothold → privilege escalation ndani ya pipeline ya CI/CD.

References

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks