Genera macchine virtuali vulnerabili al volo (lo sviluppo attuale del team avviene nel fork cliffe/SecGen)
SecGen crea macchine virtuali vulnerabili così gli studenti possono imparare le tecniche di penetration testing.
Box come Metasploitable2 sono sempre uguali; questo progetto usa Vagrant, Puppet e Ruby per creare macchine virtuali vulnerabili in modo casuale, utilizzabili per l'apprendimento o per ospitare eventi CTF.
La versione più recente è disponibile su: http://github.com/cliffe/SecGen/
Gli studenti di sicurezza informatica traggono beneficio dall'affrontare sfide di hacking. Il lavoro pratico in laboratorio e le sfide di hacking preconfigurate sono una pratica comune sia nella formazione in sicurezza sia come passatempo per gli appassionati di sicurezza. Le sfide di hacking competitive, come le competizioni capture the flag (CTF), sono diventate un punto fermo delle conferenze di settore e sono il fulcro di grandi comunità online. Le macchine virtuali (VM) forniscono un modo efficace per condividere obiettivi da hackerare e possono essere progettate per testare le capacità dell'attaccante. Siti web come Vulnhub ospitano VM di sfide di hacking preconfigurate e rappresentano una risorsa preziosa per chi apprende e migliora le proprie competenze nella sicurezza informatica. Tuttavia, sviluppare queste sfide di hacking richiede tempo e, una volta create, sono essenzialmente statiche. Cioè, una volta che la sfida è stata "risolta" non rimane alcuna sfida per lo studente, e se la sfida è creata per una competizione o una valutazione, non può essere riutilizzata senza rischiare plagio e collusione.
Security Scenario Generator (SecGen) genera sistemi vulnerabili randomizzati. Le VM vengono create sulla base di una specifica di scenario, che descrive i vincoli e le proprietà delle VM da creare. Ad esempio, uno scenario potrebbe specificare la creazione di un sistema con una vulnerabilità sfruttabile da remoto che porterebbe a un compromesso a livello di utente, e un difetto sfruttabile localmente che porterebbe a un compromesso a livello di root. Ciò richiederebbe all'attaccante di scoprire e sfruttare entrambe le vulnerabilità selezionate casualmente per ottenere accesso root al sistema. In alternativa, lo scenario definito può essere più specifico, indicando determinati tipi di servizi (come FTP o SMB) o persino vulnerabilità esatte (per CVE).
SecGen è un'applicazione Ruby, con un linguaggio di configurazione XML. SecGen legge la propria configurazione, incluse le vulnerabilità, i servizi, le reti, gli utenti e i contenuti disponibili, legge la definizione dello scenario richiesto, applica una logica per randomizzare lo scenario e si avvale di Puppet e Vagrant per il provisioning delle VM richieste.
SecGen è software libero: puoi ridistribuirlo e/o modificarlo secondo i termini della GNU General Public License come pubblicata dalla Free Software Foundation, sia la versione 3 della Licenza, sia (a tua scelta) qualsiasi versione successiva.
SecGen contiene moduli che installano vari pacchetti software. Ogni modulo di SecGen può contenere software o ottenerlo da remoto, e ogni modulo definisce la propria licenza nel file secgen_metadata.xml allegato.
SecGen è sviluppato e testato su Ubuntu Linux. In teoria, SecGen dovrebbe funzionare su Mac o Windows, se hai installato tutto il software richiesto.
Dovrai installare quanto segue:
Installa tutti i pacchetti richiesti:```bash
wget https://releases.hashicorp.com/vagrant/1.9.8/vagrant_1.9.8_x86_64.deb sudo apt install ./vagrant_1.9.8_x86_64.deb
sudo apt-get install ruby-dev zlib1g-dev liblzma-dev build-essential patch virtualbox ruby-bundler imagemagick libmagickwand-dev exiftool libpq-dev libcurl4-openssl-dev libxml2-dev
Copia SecGen in una directory a tua scelta, ad esempio */home/user/bin/SecGen*
Poi installa le gemme:```bash
cd /home/user/bin/SecGen
bundle install
Utilizzo di base:```bash ruby secgen.rb run
Questo utilizzerà lo scenario predefinito per generare casualmente una o più VM.
SecGen accetta argomenti per modificare il suo comportamento; gli argomenti attualmente implementati sono:
-```bash
ruby secgen.rb [--options] <command>
OPTIONS:
--scenario [xml file], -s [xml file]: set the scenario to use
(defaults to scenarios/default_scenario.xml)
--project [output dir], -p [output dir]: directory for the generated project
(output will default to projects/SecGen_DATEandTIME)
--shutdown: Shutdown vms after provisioning
--network-ranges: Override network ranges within the scenario, use a comma-separated list
--forensic-image-type [image type]: Forensic image format of generated image (raw, ewf)
--read-options [conf path]: Reads options stored in file as arguments (see example.conf)
--help, -h: Shows this usage information
VIRTUALBOX OPTIONS:
--gui-output', '-g': gui output
--nopae: disable PAE support
--hwvirtex: enable HW virtex support
--vtxvpid: enable VTX support
OVIRT OPTIONS:
--ovirtuser [ovirt_username]
--ovirtpass [ovirt_password]
--ovirt-url [ovirt_api_url]
--ovirt-cluster [ovirt_cluster]
--ovirt-network [ovirt_network_name]
COMMANDS:
run, r: builds project and then builds the VMs
build-project, p: builds project (vagrant and puppet config), but does not build VMs
build-vms, v: builds VMs from a previously generated project
(use in combination with --project [dir])
create-forensic-image [/project/dir], v [project #]: Builds forensic images from a previously generated project
(can be used in combination with --project [dir])
list-scenarios: Lists all scenarios that can be used with the --scenario option
list-projects: Lists all projects that can be used with the --project option
delete-all-projects: Deletes all current projects in the projects directory
SecGen genera VM basate su una specifica di scenario, che descrive i vincoli e le proprietà delle VM da creare.
Gli scenari esistenti abbassano la barriera d'ingresso per SecGen: quando si invoca SecGen, uno scenario può essere specificato come argomento da riga di comando, e SecGen leggerà quindi la definizione dello scenario appropriato e procederà alla randomizzazione e alla generazione delle VM. Questo elimina la necessità per gli utenti finali del framework di comprendere la specifica di configurazione di SecGen.
Gli scenari si trovano nella directory scenarios/. Ad esempio, per avviare una VM che presenta una vulnerabilità casuale sfruttabile da remoto che porta a una compromissione a livello di utente:```bash ruby secgen.rb --scenario scenarios/examples/remotely_exploitable_user_vulnerability.xml run
#### VM per un audit di sicurezza di un'organizzazione
Per generare un insieme di VM per un'organizzazione fittizia generata casualmente, con un sistema desktop, un server web e un server intranet:```bash
ruby secgen.rb --scenario scenarios/security_audit/team_project_scenario.xml run
Si noti che il server intranet ha un mandato di sicurezza, con istruzioni per eseguire un audit di sicurezza di questi sistemi. Il sistema desktop può accedere all'intranet per consultare il mandato, ma la VM dell'attaccante (ad esempio Kali) può essere collegata solo alla NIC condivisa dal server Web per simulare la necessità di pivotare gli attacchi attraverso il server Web, poiché non può connettersi direttamente al sistema intranet. La "guida di valutazione" è sotto forma di output scenario.xml nella directory del progetto, che fornisce i dettagli dei sistemi generati.
Per generare un set di VM per una competizione CTF:```bash ruby secgen.rb --scenario scenarios/ctf/flawed_fortress_1.xml run
Nota: i flag e gli indizi sono memorizzati in marker.xml
Abbiamo anche sviluppato e rilasciato [un'interfaccia web frontend per ospitare eventi CTF](https://github.com/cliffe/flawed_fortress-secgen_ctf_frontend), un'interfaccia web frontend per ospitare eventi CTF.
### Definire nuovi scenari
Scrivere i propri scenari consente di definire una VM o un insieme di VM con una configurazione specifica o generale quanto desiderato.
La specifica degli scenari di SecGen è un'interfaccia potente per definire i vincoli dei sistemi vulnerabili da generare. Gli scenari sono definiti in file di configurazione XML che specificano i sistemi in termini di base, servizi/utility, vulnerabilità e reti.
- system: una VM
- base: un modulo SecGen che definisce la piattaforma OS (modello di VM) usata per costruire la VM
- vulnerability: un modulo SecGen che aggiunge uno stato insicuro, hackerabile (incluse vulnerabilità software realistiche note nel mondo reale o sfide di hacking inventate)
- service: un modulo SecGen che aggiunge un servizio di rete (relativamente sicuro)
- utility: un modulo SecGen che aggiunge software o modifiche di configurazione (relativamente sicuri)
- network: una scheda di rete virtuale
- generator: genera output, come testo casuale
- encoder: riceve input, come testo casuale, esegue operazioni su di esso per produrre output (come codifica/cifratura/selezione)
La logica di selezione per scegliere i moduli che soddisfano i vincoli specificati può filtrare in base a qualsiasi attributo presente nel file secgen_metadata.xml di ciascun modulo (ad esempio, livello di difficoltà e/o CVE), e qualsiasi ambiguità comporta una selezione casuale tra le opzioni corrispondenti rimanenti (ad esempio, qualsiasi vulnerabilità che corrisponda a un livello di difficoltà specificato).
Ad esempio, scenarios/simple_examples/simple_any_random_vulnerability.xml specifica un sistema con una base Debian Linux e una vulnerabilità. In questo caso il modulo base è specificato per nome del modulo, quindi questa selezione è predefinita (esiste un solo modulo possibile che corrisponde), e la vulnerabilità è selezionata casualmente dall'intero insieme di vulnerabilità perché non sono specificati filtri sugli attributi, che avrebbero potuto limitare le corrispondenze potenziali.```xml
<?xml version="1.0"?>
<scenario xmlns="http://www.github/cliffe/SecGen/scenario"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.github/cliffe/SecGen/scenario">
<system>
<system_name>random_server</system_name>
<base module_path="modules/bases/debian_puppet_32"/>
<vulnerability />
</system>
</scenario>
Nota che i filtri specificati sono corrispondenze tramite espressioni regolari (regexp). Ad esempio, qui il module_path è qualsiasi valore che corrisponde a qualsiasi cosa seguita da "distcc":```xml
distcc_server<vulnerability module_path=".*distcc" />
<network type="private_network" range="dhcp" />
<vulnerability privilege="user_rwx" access="remote" />
<vulnerability privilege="root_rwx" access="local" />
<service/>
<network type="private_network" range="dhcp"/>
Nota che, con l'eccezione di \<system_name>, tutti gli elementi XML all'interno di \<system> si risolveranno nell'aggiunta di un modulo SecGen (un singolo modulo, più eventuali dipendenze e valori predefiniti). Gli attributi specificati restringono l'insieme di moduli tra cui scegliere casualmente. Ad esempio, la scheda di rete viene selezionata dai moduli SecGen disponibili per schede di rete che sono private_networks con dhcp.
#### Scenari avanzati: parametrizzazione
Ad alcuni moduli può essere fornito un input. Ad esempio, a una vulnerabilità possono essere fornite informazioni da divulgare come output. In questo caso, una condivisione NFS ospiterà un file esportato pubblicamente contenente il testo divulgato:```xml
<?xml version="1.0"?>
<scenario xmlns="http://www.github/cliffe/SecGen/scenario"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.github/cliffe/SecGen/scenario">
<system>
<system_name>file_server</system_name>
<base platform="linux"/>
<vulnerability module_path=".*nfs_overshare">
<input into="strings_to_leak">
<value>Leak this text, and a randomly generated flag</value>
<generator type="flag_generator"/>
</input>
</vulnerability>
<network type="private_network" range="dhcp"/>
</system>
</scenario>
Encoder, generator e valori letterali possono essere annidati.
I parametri dei moduli SecGen sono analoghi ai parametri denominati e (sempre) facoltativi (ad esempio, come in C#).
Quanto sopra può essere illustrato in pseudocodice:```C // This is just some pseudo code to help explain vulnerabilty_nfs_overshare(strings_to_leak: ["Leak this text, and a randomly generated flag", generator_flag()]);
Un altro esempio, come sopra, ma il messaggio e il flag vengono prima codificati in base64:```xml
<?xml version="1.0"?>
<scenario xmlns="http://www.github/cliffe/SecGen/scenario"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.github/cliffe/SecGen/scenario">
<system>
<system_name>file_server</system_name>
<base platform="linux"/>
<vulnerability module_path=".*nfs_overshare">
<input into="strings_to_leak">
<encoder name="BASE64 Encoder">
<input into="strings_to_encode">
<value>Leak this text, and a randomly generated flag</value>
<generator type="flag_generator"/>
</input>
</encoder>
</input>
</vulnerability>
<network type="private_network" range="dhcp"/>
</system>
</scenario>
Generatori ed encoder produrranno/restituiranno sempre un array (senza nome) di Stringhe, che può essere indirizzato ai parametri di input di altri moduli (tramite il nome del parametro nei moduli in cui sono annidati, come illustrato sopra).
Tutti gli encoder accetteranno ed elaboreranno il parametro "strings_to_encode", quindi è sicuro passare l'input a qualsiasi encoder selezionato casualmente (anche se potresti voler filtrare per encoder reversibili per una sfida di decodifica, come mostrato di seguito). È possibile indirizzare l'output di più moduli all'input dello stesso parametro di un modulo. Ad esempio:```xml
<system>
<system_name>file_server</system_name>
<base platform="linux"/>
<vulnerability module_path=".*nfs_overshare">
<input into="strings_to_leak">
<!--output from this encoder...-->
<encoder type="ascii_reversible">
<input into="strings_to_encode">
<generator type="flag_generator" />
</input>
</encoder>
<!--and from this generator:-->
<generator type="flag_generator" />
</input>
</vulnerability>
<network type="private_network" range="dhcp"/>
</system>
In questo caso ciascuno degli input annidati a quello stesso parametro viene concatenato nello stesso array di stringhe. Questo è grosso modo analogo a:```C
// This is just some pseudo code to help explain
// (C#-like methods with named arguments)
vulnerability_nfs_share_leak(strings_to_leak: encoder_selected_ascii_reversible(strings_to_encode: encoder_flag_generator()) CONCATENATE_WITH encoder_flag_generator());
Potresti voler scrivere a qualsiasi modulo che abbia un parametro particolare: ad esempio, una vulnerabilità che ha un parametro "strings_to_leak", ovvero una vulnerabilità che, quando sfruttata, rivela stringhe all'attaccante: ```xml
<system>
<system_name>file_server</system_name>
<base platform="linux"/>
<!--this line selects a vulnerability that can leak strings:-->
<vulnerability read_fact="strings_to_leak">
<input into="strings_to_leak">
<encoder type="ascii_reversible">
<input into="strings_to_encode">
<generator type="flag_generator" />
</input>
</encoder>
<generator type="flag_generator" />
</input>
</vulnerability>
<network type="private_network" range="dhcp"/>
</system>
I parametri accettati da ciascun modulo sono elencati nel file secgen_metadata.xml di ciascun modulo, come descritto di seguito.
#### Scenari avanzati: Garantire che i moduli selezionati siano unici
Se desideri utilizzare una serie di moduli per generare input per i parametri di un altro modulo, puoi specificare un elenco (denominato) per escludere i moduli dall'essere selezionati più di una volta.```xml
[snip]
<vulnerability name="NFS Share Leak">
<input into="strings_to_leak" unique_module_list="unique_encoders">
<encoder type="ascii_reversible">
<input into="strings_to_encode">
<generator type="flag_generator" />
</input>
</encoder>
<encoder type="alpha_reversible">
<input into="strings_to_encode">
<generator type="flag_generator" />
</input>
</encoder>
<encoder type="alpha_reversible">
<input into="strings_to_encode">
<generator type="flag_generator" />
</input>
</encoder>
</input>
</vulnerability>
[snip]
Il "unique_module_list='unique_encoders'" garantisce che gli encoder selezionati non vengano ripetuti.
I datastore sono essenzialmente variabili in cui puoi scrivere e poi riutilizzare. Questo è simile alle "variabili" in altri linguaggi. Tuttavia, un datastore contiene sempre un array di stringhe e scrivere nel datastore concatena l'array di stringhe.
Puoi usare i datastore per catturare valori. Qui generiamo due flag e li memorizziamo nello stesso datastore:```xml
Qui generiamo due flag e li memorizziamo in datastore separati.```xml
<input into_datastore="flag1">
<generator type="flag_generator" />
</input>
<input into_datastore="flag2">
<generator type="flag_generator" />
</input>
Possiamo quindi passare il datastore (flag2) a un parametro del modulo e catturare l'output in un datastore separato (encoded_flag):```xml
<input into_datastore="encoded_flag">
<encoder type="ascii_reversible">
<input into="strings_to_encode">
<datastore>flag2</datastore>
</input>
</encoder>
</input>
E far trapelare il risultato tramite una vulnerabilità:```xml
<!-- vulnerability_nfs_share(strings_to_leak: encoded_flag CONCAT flag1) -->
<vulnerability name="NFS Share Leak">
<input into="strings_to_leak" unique_module_list="unique_encoders">
<datastore>encoded_flag</datastore>
<datastore>flag1</datastore>
</input>
</vulnerability>
Puoi usare i datastore per memorizzare informazioni generate per scenari complessi, come il nome dell'organizzazione, i dipendenti e così via. Poi puoi passare queste informazioni a siti web, servizi, account utente e così via. Per un esempio dettagliato, vedi lo scenario di audit di sicurezza del progetto team:scenarios/security_audit/team_project_scenario.xml
It is also possible to iterate through a datastore, and feed each value into separate modules. This is illustrated in:
scenarios/examples/datastore_examples/iteration_and_element_access.xml
Alcuni generatori generano contenuti strutturati in formato JSON, ad esempio il tipo di organizzazione. È possibile accedere a un particolare elemento di dati strutturati da un datastore con il metodo access_json utilizzando il formato di ricerca hash di Ruby. Vedi lo scenario di esempio:scenarios/examples/datastore_examples/json_selection_example.xml
Some scenarios require VMs IP addresses to be used as parameters for other modules in the scenario. If this is the case, you should use the 'IP_addresses' datastore to store the IPs for all VMs in the scenario and use the access functionality to pass them into network modules.For example:
scenarios/examples/datastore_examples/network_ip_datastore_example.xml
SecGen è progettato per essere facilmente estendibile con moduli che definiscono vulnerabilità e altri tipi di modifiche a software, configurazione e contenuti.
Come affermato sopra, i tipi di moduli supportati da SecGen sono:
Ogni modulo di vulnerabilità è contenuto all'interno dell'albero di directory modules/vulnerabilies, organizzato per corrispondere alla struttura delle directory dei moduli di Metasploit Framework (MSF). Ad esempio, il modulo di vulnerabilità distcc_exec è contenuto in: modules/vulnerabilities/unix/misc/distcc_exec/.
La radice della directory del modulo contiene sempre un file secgen_metadata.xml e include anche file puppet, usati per rendere vulnerabile un sistema.
Il file secgen_metadata.xml definisce gli attributi del modulo. Nel caso dei moduli di vulnerabilità, questo file contiene informazioni sulla vulnerabilità, tra cui CVE, livello di privilegio che l'attaccante riesce a ottenere, livello di accesso richiesto per attaccare (remoto vs locale), modulo metasploit che può essere usato per sfruttare la vulnerabilità, punteggio CVSS e stringa vettoriale, livello di difficoltà e descrizione.
Queste informazioni sono usate per filtrare la selezione dei moduli per gli scenari, e anche per specificare moduli che sono in conflitto tra loro o per soddisfare dipendenze tra moduli.
Esempio:```xml
DistCC Daemon Command Execution Lewis Ardern <module_license>MIT</module_license> Distcc has a documented security weakness that enables remote code execution.
distcc user_rwx remote unix
medium CVE-2004-2687 <cvss_base_score>9.3</cvss_base_score> <cvss_vector>AV:N/AC:M/Au:N/C:C/I:C/A:C</cvss_vector> https://www.rapid7.com/db/modules/exploit/unix/misc/distcc_exec OSVDB-13378 <software_name>distcc</software_name> <software_license>GPLv2</software_license>
<msf_module>exploit/unix/misc/distcc_exec</msf_module> On a non-standard port Distcc is vulnerable, and on a high port number.
distcc ``` #### name Il nome del modulo, con spazi e parole in maiuscolo iniziale (Title Case).Ripetuto una o più volte per gli autori del modulo SecGen e per riconoscere eventuali autori di moduli Puppet adattati da PuppetForge.
La licenza libera e open source con cui il modulo è rilasciato.
Una descrizione del modulo e di cosa fa.
Una categoria generale, in termini di protocollo di rete utilizzato (ad esempio, ftp) se rilevante.
Il livello di privilegio con cui un attaccante conclude quando lo sfruttamento ha successo.
Perdita di informazioni: info_leak (ad es. nfs/nfs_overshare)
Accesso a una shell: root_rwx, user_rwx (ad es. local/setuid_nmap, smb/samba_symlink_traversal)
Accesso in lettura e scrittura: root_rw, user_rw (ad es. access_control_misconfigurations/uid_vi_root, smb/samba_public_writable_share)
Accesso in lettura: root_r (ad es. access_control_misconfigurations/uid_less_root)
Man mano che verranno aggiunte altre sfide, verranno aggiunte le perdite di database come opzione di livello di privilegio.
Il livello di accesso di cui l'attaccante ha bisogno per eseguire l'attacco. Accesso locale, come una shell esistente o un account utente, o remoto, come un servizio di rete vulnerabile.
Con quali sistemi operativi il modulo è compatibile.
Quanto è difficile la sfida.
Per vulnerabilità reali, il CVE quando disponibile.
Il punteggio base CVSS v2. Il punteggio come calcolato in base al vettore CVSS.
La stringa del vettore CVSS v2, ad esempio: 'AV:L/AC:H/Au:N/C:N/I:P/A:C'
Vettore di accesso (AV): L = accesso locale, A = accesso adiacente, N = accesso di rete
Complessità di accesso (AC): H = Alta, M = Media, L = Bassa
Autenticazione (Au): N = nessuna richiesta, S = istanza singola, M = istanze multiple
Impatto sulla riservatezza (C): N = Nessuno, P = Parziale, C = Completo
Impatto sull'integrità (I): N = Nessuno, P = Parziale, C = Completo
Impatto sulla disponibilità: N = Nessuno, P = Parziale, C = Completo
NIST mette a disposizione un comodo strumento online.
Ripetuto per URL con ulteriori informazioni su vulnerabilità, exploit e software. Ad esempio, informazioni sulla vulnerabilità, collegamenti agli exploit e così via.
Nome del pacchetto del software installato dai moduli Puppet (come indicato nei repository software).
La licenza del software installato/incluso.
Un modulo Metasploit (se esiste) per compromettere la vulnerabilità. Ad esempio, "exploit/unix/misc/distcc_exec".
Un suggerimento per indirizzare l'attaccante nella giusta direzione.
Una soluzione alla sfida.
Un modulo può essere in conflitto con altri moduli in base alla corrispondenza di attributi o module_path. Ogni conflitto può avere più condizioni che devono essere tutte soddisfatte perché venga considerato un conflitto.
Ad esempio, per essere in conflitto con i moduli che forniscono un server web e installano apache:```xml httpd <software_name>apache</software_name>
That example would not conflict with other web servers that don't include "apache" in the software_name.
If multiple \<conflict> elements are specified, it only takes any one conflict to prevent a conflicting module to be selected.
When creating modules, __conflicts should be avoided wherever possible__, as they can significantly reduce the randomisation options for complex scenarios, and can cause complications in the resolution of scenarios (which is currently solved via bruteforce).
#### requires (opzionale)
Un modulo può includere tag \<requires> per richiedere che anche altri moduli che soddisfano un insieme di condizioni vengano aggiunti allo scenario. Quando si seleziona un modulo, ciascuna di queste dipendenze viene risolta verificando se è già stato selezionato un modulo che soddisfa la condizione; in tal caso non accade nulla, altrimenti viene selezionato casualmente un modulo che soddisfa tutte le condizioni e aggiunto allo scenario. Il processo è ricorsivo, quindi un modulo può richiedere moduli che a loro volta richiedono altri moduli.
Quando si verificano conflitti (ad esempio, se un modulo precedentemente selezionato è in conflitto con tutte le opzioni valide per risolvere una dipendenza), lo scenario viene rigenerato. Questo approccio bruteforce è piuttosto efficace, ma i tag \<conflict> dovrebbero essere evitati il più possibile perché aggiungono complessità e riducono le possibilità di randomizzazione.
Un modulo può avere più \<requires>, ciascuno dei quali garantirà che un singolo modulo soddisfi tutte le condizioni, che sono corrispondenze regexp sugli attributi.
Ad esempio, per un modulo che necessita prima di un aggiornamento del repository (apt-get update):```xml
<requires>
<type>update</type>
</requires>
Oppure per un modulo che richiede che apache venga installato da un altro modulo (piuttosto che il modulo stesso installi apache, in alternativa):```xml httpd <software_name>apache</software_name>
In questo (sciocco) esempio, writable_shadow richiede apache che richiede update:
In un altro esempio sciocco, qui apache richiede ftp, ma tutti i moduli ftp sono in conflitto con writable_shadow:
#### read_fact (opzionale)
Un modulo può dichiarare che utilizza gli input che riceve. I parametri di input più comuni sono "strings_to_encode" e "strings_to_leak". read_fact può anche essere ripetuto per qualsiasi altro parametro di configurazione del modulo.
#### default_input (opzionale)
Una definizione di modulo può specificare input predefiniti da usare quando nessuno viene specificato tramite lo scenario. Ciò significa che se un modulo di vulnerabilità viene selezionato senza input (ad esempio, selezionato casualmente tra tutte le vulnerabilità), l'input per i parametri di quel modulo può essere generato automaticamente.
Ad esempio:
secgen_metadata.xml:```xml
<read_fact>strings_to_leak</read_fact>
<!--if an input is not specified in the scenario-->
<default_input into="strings_to_leak">
<value>Plain text from the metadata default, destined for strings_to_leak...</value>
</default_input>
<default_input into="some_random_setting">
<value>true</value>
</default_input>
Nota che lo scenario potrebbe selezionare e inoltrare parametri specifici:
scenario.xml:```xml LEAK THIS!
Nel caso precedente, il parametro "some_random_setting" assumerebbe il suo valore predefinito (["true"]), e le stringhe divulgate sarebbero il valore proveniente dallo scenario (["LEAK THIS!"]).
I valori dei parametri possono essere selezionati casualmente tramite il modulo encoder di selezione casuale. Ad esempio:
secgen_metadata.xml:```xml
<default_input into="some_random_setting">
<encoder name="Random String Selector">
<value>true</value>
<value>false</value>
</encoder>
</default_input>
Di conseguenza, ogni volta che il modulo viene utilizzato, verrebbe configurato in modo casuale, a meno che non sia specificamente indicato nello scenario.
Gli input predefiniti possono anche essere costruiti utilizzando generatori e codificatori nidificati complessi:
secgen_metadata.xml:```xml <read_fact>strings_to_leak</read_fact>
<default_input into="strings_to_leak"> Plain text from the metadata default, destined for strings_to_leak... Encoded text from the metadata default, destined for strings_to_leak... More encoded text from the metadata default, destined for strings_to_leak... </default_input>
### Puppet files
Ogni modulo di vulnerabilità, servizio e utility contiene file Puppet che vengono utilizzati per il provisioning del software sulle VM.
La directory del modulo contiene
- un modulo Puppet
- punto di ingresso Puppet (stesso nome file della directory del modulo, .pp)
Questo esempio dovrebbe aiutare a illustrare. Distcc ha una debolezza di sicurezza documentata che consente l'esecuzione remota di codice. L'esempio seguente proviene da modules/vulnerabilities/misc/distcc_exec.
Una directory manifest/ contiene i file Puppet per una classe Puppet distcc_exec.
Come da convenzione, un file per l'installazione:````
class distcc_exec::install{
package { 'distcc':
ensure => installed
}
}
Un file per la configurazione (più un file modello):```` class distcc_exec::config{ file { '/etc/default/distcc': require => Package['distcc'], ensure => present, owner => 'root', group => 'root', mode => '0777', content => template('distcc_exec/distcc.erb') } }
Un file per garantire che il servizio si avvii:````
class distcc_exec::service{
service { 'distcc':
ensure => running
}
}
Finora questo è tutto tipico Puppet.
Infine, aggiungiamo un punto di ingresso del modulo, con lo stesso nome della directory .pp:```` include distcc_exec::install include distcc_exec::config include distcc_exec::service
Per saperne di più su Puppet e capire come scrivere moduli, consulta il wiki di SecGen e anche http://puppetlabs.com/
### local/secgen_local.rb
Encoder e generatori contengono codice che viene valutato al momento della build del progetto, come la codifica del testo e la generazione di flag e altri contenuti. In ogni caso, si tratta di uno script Ruby situato nella directory del modulo, in local/secgen_local.rb. Sebbene normalmente chiamati da SecGen, gli script secgen_local.rb possono essere eseguiti direttamente, accettano tutti gli input dei parametri come argomenti della riga di comando e restituiscono l'output in formato JSON su stdout. Altro output leggibile dall'uomo viene scritto su stderr.```bash
#ruby modules/encoders/string/base64/secgen_local/local.rb --strings_to_encode "encode this" --strings_to_encode "and this"
BASE64 Encoder
Encoding '["encode this", "and this"]'
Encoded: ["ZW5jb2RlIHRoaXM=", "YW5kIHRoaXM="]
["ZW5jb2RlIHRoaXM=","YW5kIHRoaXM="]
```
## Output del progetto SecGen
Di default, l'output viene salvato in projects/SecGen_[CurrentTime]/
L'output del progetto include:
- Una configurazione Vagrant per avviare i box.
- Una directory contenente tutti i moduli Puppet richiesti per quanto sopra. Viene creato un file Librarian-Puppet per gestire i moduli e alcuni moduli richiesti possono essere ottenuti tramite PuppetForge; pertanto, è necessaria una connessione Internet durante la creazione del progetto.
- Un file XML di scenario de-randomizzato. Usando SecGen puoi utilizzare questo file scenario.xml per ricreare la configurazione Vagrant e i file Puppet di cui sopra. Eventuali randomizzazioni applicate dovrebbero essere de-randomizzate in questo output (rispetto al file di scenario originale). Questo file contiene tutti i dettagli dei sistemi creati e può anche essere usato in seguito per la valutazione, il punteggio o per fornire suggerimenti.
- Un file marker.xml utile per eventi CTF, contenente tutte le flag insieme a più suggerimenti per ciascuna flag. Può essere usato per configurare il frontend CTF.
Se avvii SecGen con il comando "build-project" (o "p"), crea i file di cui sopra e poi si ferma. Il comando "run" (o "r") crea i file del progetto e poi usa Vagrant per costruire le VM.
È possibile copiare la directory del progetto su qualsiasi sistema compatibile con Vagrant ed eseguire semplicemente "vagrant up" per creare le VM.
La password di root predefinita per i base-box è 'puppet', ma può essere modificata da SecGen a seconda dello scenario utilizzato.
## Roadmap
- **Più moduli!** Inclusi più moduli in stile CTF.
- Basebox Windows e vulnerabilità.
- Output di laboratori di sicurezza (randomizzati) con fogli di lavoro.
- Distribuzione su cloud.
- Ulteriore gamification e scenari immersivi.
## Riconoscimenti
*Team di sviluppo:*
- Dr Z. Cliffe Schreuders http://z.cliffe.schreuders.org
- Tom Shaw
- Jason Keighley
- Lewis Ardern -- autore della prima release proof-of-concept di SecGen
- Connor Wilson
Grazie di cuore a tutti coloro che hanno contribuito al progetto. L'elenco sopra non è completo né esaustivo; fai riferimento alla [storia di GitHub](https://github.com/cliffe/SecGen/graphs/contributors).
Questo progetto è supportato da un finanziamento della Higher Education Academy (HEA) per l'apprendimento e l'insegnamento della cyber security (2015-2017).
## Contributi
Incoraggiamo i contributi al progetto; consulta la wiki per le indicazioni su come contribuire.
In breve: fai un fork da http://github.com/cliffe/SecGen/, crea un branch, apporta e committa le tue modifiche, quindi crea una pull request.
## Risorse
Paper: [Z.C. Schreuders, T. Shaw, M. Shan-A-Khuda, G. Ravichandran, J. Keighley, M. Ordean, "Security Scenario Generator (SecGen): A Framework for Generating Randomly Vulnerable Rich-scenario VMs for Learning Computer Security and Hosting CTF Events," USENIX Workshop on Advances in Security Education (ASE'17), Vancouver, BC, Canada. USENIX Association, 2017.](https://www.usenix.org/conference/ase17/workshop-program/presentation/schreuders) (Questo articolo fornisce una buona panoramica di SecGen.)
Paper: [Z.C. Schreuders, and L. Ardern, "Generating randomised virtualised scenarios for ethical hacking and computer security education: SecGen implementation and deployment," in The first UK Workshop on Cybersecurity Training & Education (Vibrant Workshop 2015) Liverpool, UK, 2015.](http://z.cliffe.schreuders.org/publications/VibrantWorkshop2015%20-%20Generating%20randomised%20virtualised%20scenarios%20for%20ethical%20hacking%20and%20computer%20security%20education%20%28SecGen%29.pdf) (Questo articolo descrive il primo prototipo.)
Intervista podcast: [Purple Squad Security Episode 011 – Security Scenario Generator with Dr. Z. Cliffe Schreuders](https://purplesquadsec.com/podcast/episode-011-security-scenario-generator-dr-z-cliffe-schreuders/)