Nell’ ultimo articolo della serie creare un laboratorio di Penetration test con Ansible dopo aver visto come effettuare le configurazioni per gestire tutti gli host da una macchina Ansible e dopo aver costruito una server bersaglio ci concentriamo sulla creazione della macchina di attacco.

Penetration test: distro più famose

Potremmo limitarci ad utilizzare una tra le più famose distribuzioni Linux come Kali Linux, Backbox, Parrot, BlackArch. Visto che per anni la mia attività è stata eseguire penetration test sono consapevole che ogni Ethical Hacker preferisce avere a disposizione una distro personalizzata con a bordo i tool più consoni alla proprie esigenze. Oltretutto spesso volevo avere a disposizione tool o script sviluppati da me e opportunamente modellati. Pertanto andremo ad analizzare il progetto ThreatBox che basa la creazione proprio sullo scopo di personalizzazione la dotazione di bordo.

Red teaming: ThreatBox

Come si legge dalla documentazione l’approccio adottato dal creatore di ThreatBox è utilizzare playbook e ruoli Ansible per creare una piattaforma con una dotazione personalizzata partendo da un sistema operativo base (Ubuntu). L’approccio è molto interessante considerando che con tale modalità si possono creare non solo strumenti per i penetration test ma anche infrastrutture complesse per supportare attività di red teaming, esempio centri di comando e controllo. Allo stesso tempo una volta costruiti i playbook essenziali il processo per ricreare un sistema è ripetibile e scalabile.

Il founder del progetto ha scritto un libro dal titolo Red Team Development and Operations: A practical guide che approfondisce i concetti di red teaming e threat emulation nonchè della gestione di tali attività.

ThreatBox: gestione delle variabili

Per essere un sistema modulare è necessario predisporre un repository nel quale sono contenute tutte le variabili. Nel progetto le variabili sono indicate in formato YAML nel file threatbox.yml localizzato nella cartella Group vars.

Ecco alcune variabili che è possibile modificare: 

  • username e password per accedere alla piattaforma
  • chiave private per accesso in ssh
  • porta su cui gira il servizio ssh
  • repository git per l’installazione dei package via apt
  • le informazioni per il download e creazione dei file, come le wordlist per eseguire attacchi brute force

La modifica della chiave ssh è importante per includere la chiave disponibile dal nodo Ansible centralizzato e permettere ulteriori personalizzazioni direttamente dal nodo creato in precedenza.

Threatbox: tool

I tool presenti nella conformazione standard sono definiti come role Ansible e collezionati nella cartella roles. Tra di essi: 

  • Burpsuite: il mio tool preferito per eseguire Web Application Penetration Test
  • Impacket: suite utilissima per interagire con protocolli e pacchetti
  • John the ripper: per il password cracking
  • Metasploit: lo strumento più utilizzato per exploiting
  • Bloodhound: per il test di Active Directory

Ansible roles

I roles Ansible sono una struttura predefinita ideata per permette il riutilizzo delle funzioni.

I ruoli sono una sorta di programma richiamabili con diverse modalità (statica e dinamica) e con la possibilità di passare delle variabili. Non scenderò nel dettaglio ma la documentazione è molto accurata e sono disponibili delle funzioni già implementati in un repository chiamato Ansible Galaxy.

Per capire i roles e come essi vengono adoperati da Threatbox analizzeremo il caso di Burp Suite. Notiamo che nella directory rispetto alla conformazione standard di un ruole Ansible ci sono solamente tre cartelle:

  • tasks
  • meta
  • defaults

Il motivo è che le directory standard se non utilizzate possono essere omesse.

Ansible Tasks

Contiene i task eseguiti dal ruolo. In questo caso lo scopo è installare Burp suite Community e nel primo step viene definito il valore della variabile path .

I commenti del task evidenziano il concetto di modularità e gestione delle variabili espresso in precedenza in quanto il task utilizza le informazioni scritte nel file threatbox.yml per effettuare il download del tool.

## tasks main.yml for role: Burpsuite
## This role installs Burpsuite Community

###########################
## Install Burpsuite

## Note: Download of the source is controlled in the threatbox.yml file. 
##       It's best to enable all downloads in that file. 
##       This help to maintain software package tracking.

- name: Set burpsuite path variable
  set_fact:
      tool_path: "{{ tools_root }}/{{ item.value.category }}/{{ item.key }}/"
  loop: "{{ lookup('dict', direct_download_files) }}"
  when: "'burpsuite' in item.key" 

### Check if tool_path exists
- name: check for tool_path ({{ tool_path }})
  stat:
    path: "{{ tool_path }}"
  register: tp

- name: fail if tool_path ({{ tool_path }}) does not exist
  fail: msg="The directory does not exist"
  when: not tp.stat.exists  

- name: Install burp suite community quietly
  shell: "{{ tool_path }}/burpsuite_community_linux_v2020_1.sh -q"
  loop: "{{ lookup('dict', direct_download_files) }}"
  when: "'burpsuite' in item.key" 
  args:
    chdir: "{{ tool_path }}"

Meta

Ci sono le informazioni di contesto del ruolo. In questo caso le dipendenze da altri ruoli.

---
## meta main.yml for role: burpsuite
dependencies:
  - setupssh

Defaults

La cartella defaults contiene la dichiarazione di variabili. In questo caso nel file main. yml viene definito il path dove scaricare Burp Suite con la variabile: direct_download_files.

---
## defaults main.yml for role: burpsuite

tools_root: /tools

direct_download_files:
    burpsuite:
        category: web
        url:  https://portswigger.net/burp/releases/download?product=community&version=2020.1&type=Linux

I defaults di un ruolo possono essere sovrascritti: 

  • usando una variabile omonima come parametro del role
  • utilizzando una variabile dall’inventory
  • utilizzando una variabile dal playbook
  • dalla command line di Ansible

Conclusioni

Abbiamo visto come realizzare una distro per Penetration test personalizzata mediante l’uso di Ansible. Gli stessi concetti sono applicabili per la creazione di infrastrutture complesse per attività di red teaming, semplicemente prendendo spunto da una soluzione già architettata.

Per la creazione del laboratorio il passo successivo potrebbe essere arricchire la parte di configuration managment con la creazione da zero delle vm e il networking. Questo scopo può essere raggiunto con la metodologia IAC (Infrastructure As Code).