Sploitus

Exploit for SecGen

kitploit · 2026-08-25

Exploit Code

MARKDOWN727 lines
## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-SECGEN-SECGEN
# РАЗРАБОТКА ПЕРЕМЕЩЕНА В http://github.com/cliffe/SecGen/, ЭТОТ РЕПОЗИТОРИЙ НЕ ПОДДЕРЖИВАЕТСЯ И, ВЕРОЯТНО, НЕ БУДЕТ РАБОТАТЬ!

# Генератор сценариев безопасности (SecGen)

## Краткое описание

SecGen создает уязвимые виртуальные машины, чтобы студенты могли изучать методы тестирования на проникновение в системах безопасности.

Такие образы, как Metasploitable2, всегда одинаковы. Этот проект использует Vagrant, Puppet и Ruby для создания случайным образом уязвимых виртуальных машин, которые можно использовать для обучения или для проведения CTF-мероприятий.

Последняя версия доступна по адресу: http://github.com/cliffe/SecGen/

## Введение

Студенты, изучающие компьютерную безопасность, получают пользу от участия в хакерских задачах. Практические лабораторные работы и предварительно настроенные хакерские задачи являются обычной практикой как в обучении безопасности, так и в качестве хобби для людей, интересующихся безопасностью. Соревновательные хакерские задачи, такие как соревнования Capture the Flag (CTF), стали неотъемлемой частью отраслевых конференций и являются центром больших онлайн-сообществ. Виртуальные машины (ВМ) предоставляют эффективный способ распространения целей для взлома и могут быть разработаны для проверки навыков атакующего. Такие веб-сайты, как Vulnhub, размещают предварительно настроенные хакерские задачи на ВМ и являются ценным ресурсом для тех, кто изучает и совершенствует свои навыки в области компьютерной безопасности. Однако разработка этих хакерских задач требует много времени, а после создания они по сути статичны. То есть, как только задача «решена», для студента не остается никакой дальнейшей задачи, и если задача создается для соревнования или оценки, ее нельзя использовать повторно без риска плагиата и сговора.

Генератор сценариев безопасности (SecGen) генерирует рандомизированные уязвимые системы. ВМ создаются на основе спецификации сценария, которая описывает ограничения и свойства создаваемых ВМ. Например, сценарий может задавать создание системы с удаленно эксплуатируемой уязвимостью, которая приводит к компрометации на уровне пользователя, и локально эксплуатируемым недостатком, который приводит к компрометации на уровне root. Это потребует от атакующего обнаружения и эксплуатации обеих случайно выбранных уязвимостей для получения root-доступа к системе. Альтернативно, определяемый сценарий может быть более конкретным, указывая определенные виды сервисов (такие как FTP или SMB) или даже точные уязвимости (по CVE).

SecGen — это приложение на Ruby с конфигурационным языком на основе XML. SecGen считывает свою конфигурацию, включая доступные уязвимости, сервисы, сети, пользователей и содержимое, считывает определение запрошенного сценария, применяет логику рандомизации сценария и использует Puppet и Vagrant для предоставления требуемых ВМ.

## Лицензия

SecGen является свободным программным обеспечением: вы можете распространять и/или изменять его в соответствии с условиями Стандартной общественной лицензии GNU, опубликованной Фондом свободного программного обеспечения, либо версии 3 этой лицензии, либо (по вашему выбору) любой более поздней версии.

SecGen содержит модули, которые устанавливают различные программные пакеты. Каждый модуль SecGen может содержать или удаленно получать программное обеспечение, и каждый модуль определяет свою собственную лицензию в сопутствующем файле secgen_metadata.xml.

## Установка

SecGen разрабатывается и тестируется на Ubuntu Linux. Теоретически SecGen должен работать на Mac или Windows, если у вас установлено все необходимое программное обеспечение.

Вам потребуется установить следующее:

  * Ruby (development): https://www.ruby-lang.org/en/
  * Vagrant: http://www.vagrantup.com/
  * Virtual Box: https://www.virtualbox.org/
  * Puppet: http://puppet.com/
  * Packer: https://www.packer.io/
  * ImageMagick: https://www.imagemagick.org/
  * А также необходимые Ruby Gems (включая Nokogiri и Librarian-puppet)



### В Ubuntu эти команды помогут вам начать работу

Установите все необходимые пакеты:```bash

# install a recent version of vagrant

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

# install other required packages via repos

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

root@kitploit:~
    
    
    Скопируйте SecGen в каталог по вашему выбору, например */home/user/bin/SecGen*
    
    Затем установите gems:```bash
    cd /home/user/bin/SecGen
    bundle install
    

## Использование

Базовое использование:```bash ruby secgen.rb run

root@kitploit:~
    
    
    Это будет использовать сценарий по умолчанию для случайной генерации виртуальных машин.
    ![gif-анимация](https://assets.kitploit.com/production/public/readmes/39158/395bfb94e9b15b2c52f91fd33626216df86d8e2422789fb2a080b9b75fa36513.gif "SecGen рандомизирует уязвимую ВМ -- часть 1, рандомизация")
    ![gif-анимация](https://assets.kitploit.com/production/public/readmes/39158/756677cacb4f7cef9ff4c45b67ab41a7eca70d8a1cdcbaa32cd262fe4c317f47.gif "SecGen рандомизирует уязвимую ВМ -- часть 2, подготовка ВМ")
    
    SecGen принимает аргументы для изменения своего поведения, текущие реализованные аргументы:```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 создает виртуальные машины на основе спецификации сценария, которая описывает ограничения и свойства создаваемых ВМ.

### Использование существующих сценариев

Существующие сценарии снижают порог входа в SecGen: при вызове SecGen можно указать сценарий в качестве аргумента команды, и SecGen затем прочитает соответствующее определение сценария и выполнит рандомизацию и генерацию ВМ. Это избавляет конечных пользователей фреймворка от необходимости понимать конфигурационную спецификацию SecGen.

Сценарии можно найти в каталоге `scenarios/`. Например, чтобы запустить ВМ со случайной удаленно эксплуатируемой уязвимостью, приводящей к компрометации на уровне пользователя:```bash ruby secgen.rb --scenario scenarios/examples/remotely_exploitable_user_vulnerability.xml run

root@kitploit:~
    
    
    ![gif-анимация](https://assets.kitploit.com/production/public/readmes/39158/9a8205377d4c414f89bfede6c3a360dfe473273653ac3c18b7574ffbead0553d.gif "Удаленно эксплуатируемый пример, где атакующий получает доступ на уровне пользователя")
    
    #### Виртуальные машины для аудита безопасности организации
    Для генерации набора виртуальных машин для случайно сгенерированной вымышленной организации, включающей настольную систему, веб-сервер и сервер интранета:```bash
       ruby secgen.rb --scenario scenarios/security_audit/team_project_scenario.xml run
    

Обратите внимание, что сервер интрасети имеет задачи безопасности с инструкциями по проведению аудита безопасности этих систем. Настольная система может получить доступ к интрасети для ознакомления с задачами, но виртуальная машина атакующего (например, Kali) может быть подключена только к сетевому интерфейсу (NIC), который разделяется веб-сервером, чтобы имитировать необходимость проведения атак через веб-сервер, поскольку она не может подключиться к системе интрасети напрямую. «Руководство по оценке» представлено в виде выходного файла scenario.xml в каталоге проекта, который содержит подробную информацию о сгенерированных системах.

#### Виртуальные машины для мероприятия CTF

Для генерации набора виртуальных машин для соревнования CTF:```bash ruby secgen.rb --scenario scenarios/ctf/flawed_fortress_1.xml run

root@kitploit:~
    
    
    Обратите внимание, флаги и подсказки хранятся в marker.xml
    
    Мы также разработали и опубликовали [веб-интерфейс для проведения CTF-соревнований](https://github.com/cliffe/flawed_fortress-secgen_ctf_frontend) — веб-интерфейс для проведения CTF-событий.
    
    ### Определение новых сценариев
    Написание собственных сценариев позволяет определить одну или несколько виртуальных машин с конфигурацией, настолько конкретной или общей, насколько это необходимо.
    
    Спецификация сценариев SecGen — это мощный интерфейс для задания ограничений для генерируемых уязвимых систем. Сценарии определяются в XML-файлах конфигурации, которые описывают системы на основе базы, сервисов/утилит, уязвимостей и сетей.
    - system: виртуальная машина (VM)
    - base: модуль SecGen, определяющий платформу ОС (шаблон ВМ), используемую для построения ВМ
    - vulnerability: модуль SecGen, добавляющий небезопасное, взламываемое состояние (включая реальные уязвимости ПО, известные в реальном мире, или созданные хакерские задачи)
    - service: модуль SecGen, добавляющий (относительно безопасный) сетевой сервис
    - utility: модуль SecGen, добавляющий (относительно безопасное) программное обеспечение или изменения конфигурации
    - network: виртуальная сетевая карта
    - generator: генерирует вывод, например, случайный текст
    - encoder: принимает ввод, например, случайный текст, выполняет операции над ним для получения вывода (например, кодирование/шифрование/выбор)
    
    Логика выбора модулей для удовлетворения заданных ограничений может фильтровать по любым атрибутам в файле secgen_metadata.xml каждого модуля (например, уровень сложности и/или CVE), а любая неоднозначность приводит к случайному выбору из оставшихся подходящих вариантов (например, любая уязвимость, соответствующая заданному уровню сложности).
    
    Например, scenarios/simple_examples/simple_any_random_vulnerability.xml задает одну систему с базой Debian Linux и уязвимостью. В этом случае модуль базы задается по имени, поэтому выбор предопределен (есть только один подходящий модуль), а уязвимость выбирается случайным образом из всего набора уязвимостей, поскольку не указаны фильтры атрибутов, которые могли бы ограничить возможные совпадения.```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>
    

Обратите внимание, что указанные фильтры являются совпадениями регулярного выражения (regexp). Например, здесь module_path — это любой путь, который соответствует чему-либо, за которым следует "distcc":```xml

distcc_server

root@kitploit:~
    
    
    <vulnerability module_path=".*distcc" />
    
    <network type="private_network" range="dhcp" />
    

``` Здесь scenarios/default_scenario.xml определяет сценарий с удаленно эксплуатируемой уязвимостью, которая предоставляет доступ к учетной записи пользователя, и локально эксплуатируемой уязвимостью повышения привилегий до root.```xml 

storage_server

root@kitploit:~
    
    
    <vulnerability privilege="user_rwx" access="remote" />
    <vulnerability privilege="root_rwx" access="local" />
    
    <service/>
    
    <network type="private_network" range="dhcp"/>
    

root@kitploit:~
    
    
    Обратите внимание, что за исключением \<system_name>, все XML-элементы внутри \<system> будут приводить к добавлению модуля SecGen (одного модуля, а также любых зависимостей и значений по умолчанию). Указанные атрибуты сужают набор модулей для случайного выбора. Например, сетевая карта выбирается из доступных модулей сетевых карт SecGen, которые являются частными сетями (private_networks) с dhcp.
    
    #### Расширенные сценарии: параметризация
    Некоторые модули могут принимать входные данные. Например, уязвимости можно передать информацию для утечки в качестве выходных данных. В этом случае общая папка NFS будет содержать публично экспортируемый файл с утекшим текстом:```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>
    

Кодировщики, генераторы и литеральные значения могут быть вложенными.

Параметры модуля SecGen аналогичны именованным и (всегда) необязательным параметрам (например, как в C#).

Вышеизложенное можно проиллюстрировать на псевдокоде:```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()]);

root@kitploit:~
    
    
    Еще один пример, как выше, но сообщение и flag сначала кодируются в 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>
    

Генераторы и кодировщики всегда создают/возвращают (безымянный) массив строк, который может быть направлен во входные параметры других модулей (по имени параметра в модули, в которые они вложены, как показано выше).

Все кодировщики принимают и обрабатывают параметр "strings_to_encode", поэтому безопасно передавать входные данные любому случайно выбранному кодировщику (однако для задачи декодирования может потребоваться отфильтровать до обратимых кодировщиков, как показано ниже). Можно направить вывод из нескольких модулей на вход одного и того же параметра модуля. Например:```xml

root@kitploit:~
    
    
    <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>
    

root@kitploit:~
    
    
    В этом случае каждый из вложенных входных данных для того же параметра объединяется в один и тот же массив строк. Это примерно аналогично:```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());
    

Возможно, вы захотите написать в любой модуль, у которого есть определённый параметр: например, уязвимость с параметром "strings_to_leak", то есть уязвимость, при эксплуатации которой злоумышленнику раскрываются строки: ```xml

root@kitploit:~
    
    
    <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>
    

root@kitploit:~
    
    
    Параметры, которые принимает каждый модуль, перечислены в файле secgen_metadata.xml каждого модуля, как описано ниже.
    
    #### Расширенные сценарии: Обеспечение уникальности выбранных модулей
    
    Если вы хотите использовать несколько модулей для генерации ввода для параметров другого модуля, вы можете указать (именованный) список, чтобы исключить выбор модулей более одного раза.```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]
    

The "unique_module_list='unique_encoders'" гарантирует, что выбранные кодировщики не будут повторяться.

#### Расширенные сценарии: Использование datastore (переменных) для хранения значений для повторного использования

Datastore — это, по сути, переменные, в которые вы можете записывать значения и затем повторно использовать их. Это _похоже_ на "переменные" в других языках. Однако datastore всегда хранит массив строк, и запись в datastore добавляет значения в этот массив строк.

Вы можете использовать datastore для захвата значений. Здесь мы генерируем два флага и сохраняем их в одном и том же datastore:```xml 

root@kitploit:~
    
    
    Здесь мы генерируем два флага и сохраняем их в отдельных хранилищах данных.```xml
    		<input into_datastore="flag1">
    			<generator type="flag_generator" />
    		</input>
    		<input into_datastore="flag2">
    			<generator type="flag_generator" />
    		</input>
    

Затем мы можем передать хранилище данных (flag2) в параметр модуля и захватить вывод в отдельное хранилище данных (encoded_flag):```xml

root@kitploit:~
    
    
    	<input into_datastore="encoded_flag">
    		<encoder type="ascii_reversible">
    			<input into="strings_to_encode">
    				<datastore>flag2</datastore>
    			</input>
    		</encoder>
    	</input>
    

root@kitploit:~
    
    
    И утечка результата через уязвимость:```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>
    

Вы можете использовать хранилища данных для хранения сгенерированной информации для сложных сценариев, таких как название организации, сотрудники и так далее. Затем передавать эту информацию на веб-сайты, сервисы, учетные записи пользователей и так далее. Подробный пример см. в сценарии аудита безопасности командного проекта:`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` Некоторые генераторы создают структурированный контент в формате JSON, например тип организации. Можно получить доступ к конкретному элементу структурированных данных из хранилища с помощью access_json, используя формат поиска хэша Ruby. Смотрите пример сценария:`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`

## Modules

SecGen спроектирован так, чтобы его можно было легко расширять с помощью модулей, определяющих уязвимости и другие виды изменений программного обеспечения, конфигурации и содержимого.

Как упоминалось выше, типы модулей, поддерживаемые в SecGen:

  * base: модуль SecGen, определяющий платформу ОС (шаблон ВМ), используемую для сборки виртуальной машины
  * vulnerability: модуль SecGen, добавляющий небезопасное, взламываемое состояние (включая реалистичные программные уязвимости, известные как реальные, или искусственные задачи по взлому)
  * service: модуль SecGen, добавляющий (относительно безопасный) сетевой сервис
  * utility: модуль SecGen, добавляющий (относительно безопасное) программное обеспечение или изменения конфигурации
  * network: виртуальная сетевая карта
  * generator: генерирует вывод, например, случайный текст
  * encoder: получает входные данные, такие как текст, выполняет над ними операции для получения вывода (например, кодирование/шифрование/выборка)



Каждый модуль уязвимости находится в дереве каталогов modules/vulnerabilities, которое организовано в соответствии со структурой каталогов модулей Metasploit Framework (MSF). Например, модуль уязвимости distcc_exec находится в: modules/vulnerabilities/unix/misc/distcc_exec/.

В корне каталога модуля всегда находится файл secgen_metadata.xml, а также файлы Puppet, которые используются для приведения системы в уязвимое состояние.

### secgen_metadata.xml

Файл secgen_metadata.xml определяет атрибуты модуля. В случае модулей уязвимостей этот файл содержит информацию об уязвимости, включая CVE, уровень привилегий, который получает успешный атакующий, необходимый уровень доступа для атаки (удалённый или локальный), модуль Metasploit, который можно использовать для эксплуатации уязвимости, оценку CVSS и векторную строку, уровень сложности и описание.

Эта информация используется для фильтрации выбора модулей для сценариев, а также для указания модулей, которые конфликтуют друг с другом, или для удовлетворения зависимостей между модулями.

Пример:```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 Имя модуля, с пробелами и заглавными буквами в каждом слове. 

#### author

Повторяется один или несколько раз для авторов модуля SecGen и для указания авторов адаптированных модулей Puppet из PuppetForge.

#### module_license MIT|Apache v2

Свободная лицензия с открытым исходным кодом, под которой выпускается модуль.

#### description

Описание модуля и того, что он делает.

#### type

Общая категория, с точки зрения используемого сетевого протокола (например, ftp), если применимо.

#### privilege info_leak | root_r | root_rw | root_rwx | user_r| user_rw | user_rwx

Уровень привилегий, который получает успешный атакующий при успешной эксплуатации.

Утечка информации: info_leak (например, nfs/nfs_overshare) Доступ к оболочке: root_rwx, user_rwx (например, local/setuid_nmap, smb/samba_symlink_traversal) Доступ на чтение и запись: root_rw, user_rw (например, access_control_misconfigurations/uid_vi_root, smb/samba_public_writable_share) Доступ на чтение: root_r (например, access_control_misconfigurations/uid_less_root)

По мере добавления других заданий утечки базы данных будут добавлены как вариант уровня привилегий.

#### access remote|local

Уровень доступа, необходимый атакующему для выполнения атаки. Локальный доступ, например, существующая оболочка или учетная запись пользователя, или удаленный доступ, например, уязвимый сетевой сервис.

#### platform unix|linux

С какими ОС совместим модуль.

#### difficulty (optional) low|medium|high

Насколько сложно задание.

#### cve (optional)

Для реальных уязвимостей — CVE, если доступен.

#### cvss_base_score (optional)

Базовый балл CVSS v2. Балл, рассчитанный на основе вектора CVSS.

#### cvss_vector (optional)

Строка вектора CVSS v2, например: 'AV:L/AC:H/Au:N/C:N/I:P/A:C'

Вектор доступа (AV): L = локальный доступ, A = смежный доступ, N = сетевой доступ  
Сложность доступа (AC): H = высокая, M = средняя, L = низкая  
Аутентификация (Au): N = не требуется, S = один экземпляр, M = несколько экземпляров  
Влияние на конфиденциальность (C): N = нет, P = частичное, C = полное  
Влияние на целостность (I): N = нет, P = частичное, C = полное  
Влияние на доступность: N = нет, P = частичное, C = полное

NIST предоставляет удобный онлайн-инструмент.

#### reference (optional)

Повторяется для URL-адресов с дополнительной информацией об уязвимости, эксплойте и программном обеспечении. Например, информация об уязвимости, ссылки на эксплойты и т.д.

#### software_name (optional)

Имя пакета программного обеспечения, устанавливаемого модулями Puppet (как указано в репозиториях программного обеспечения).

#### software_license (optional) MIT|Apache v2

Лицензия установленного/встроенного программного обеспечения.

#### msf_module (optional)

Модуль Metasploit (если существует) для компрометации уязвимости. Например, "exploit/unix/misc/distcc_exec".

#### hint (optional)

Подсказка, чтобы направить атакующего в правильном направлении.

#### solution (optional)

Решение задания.

#### conflict (optional)

Модуль может конфликтовать с другими модулями на основе совпадений атрибутов или module_path. Каждый конфликт может иметь несколько условий, которые все должны быть выполнены, чтобы это считалось конфликтом.

Например, для конфликта с модулями, которые предоставляют веб-сервер и устанавливают apache:```xml  httpd <software_name>apache</software_name>

root@kitploit:~
    
    
    Этот пример не будет конфликтовать с другими веб-серверами, у которых в `software_name` не указано "apache".
    
    Если указано несколько элементов \<conflict>, для предотвращения выбора конфликтующего модуля достаточно наличия *любого* одного конфликта.
    
    При создании модулей __конфликтов следует избегать, где это возможно__, так как они могут значительно сократить возможности рандомизации для сложных сценариев и вызвать осложнения при разрешении сценариев (что в настоящее время решается методом перебора).
    
    #### requires (опционально)
    Модуль может включать теги \<requires>, чтобы затребовать добавление в сценарий других модулей, удовлетворяющих заданным условиям. При выборе модуля каждая такая зависимость разрешается путём проверки, не был ли уже выбран модуль, удовлетворяющий условию; если да, то ничего не происходит, в противном случае случайным образом выбирается модуль, удовлетворяющий всем условиям, и добавляется в сценарий. Это рекурсивно, поэтому модуль может требовать модули, которые требуют модули.
    
    При возникновении конфликтов (например, если ранее выбранный модуль конфликтует со всеми допустимыми вариантами для разрешения зависимости) сценарий генерируется заново. Такой подход перебора достаточно эффективен, но тегов \<conflict> следует избегать, где это возможно, поскольку они добавляют сложность и уменьшают возможности рандомизации.
    
    Модуль может иметь несколько элементов \<requires>, каждый из которых гарантирует, что один модуль удовлетворяет всем условиям, которые являются сопоставлениями с регулярными выражениями по атрибутам.
    
    Например, для модуля, которому сначала необходимо выполнить обновление репозитория (`apt-get update`):```xml
    <requires>
      <type>update</type>
    </requires>
    

Или для модуля, который требует, чтобы apache был установлен другим модулем (а не сам модуль устанавливает apache, альтернативно):```xml  httpd <software_name>apache</software_name>

root@kitploit:~
    
    
    В этом (глупом) примере writable_shadow требует apache, который требует update:
    ![recursive_dependencies](https://assets.kitploit.com/production/public/readmes/39158/5a123ef5d6ec76ef47fe3d6c1a6130c5249b1950bdedf3c443cbb148355e1300.png)
    
    В другом глупом примере apache требует ftp, но все модули ftp конфликтуют с writable_shadow:
    ![recursive_dependency_resolution](https://assets.kitploit.com/production/public/readmes/39158/1df519d09115c6ef57be03d0b56108a5ccf61cabae77504ab69c49a64656b487.png)
    
    #### read_fact (опционально)
    
    Модуль может объявить, что он использует получаемые им входные данные. Наиболее распространённые входные параметры: "strings_to_encode" и "strings_to_leak". read_fact также может быть повторён для любых других параметров конфигурации модуля.
    
    #### default_input (опционально)
    
    Определение модуля может задавать значения по умолчанию для входных данных, которые будут использоваться, если они не указаны в сценарии. Это означает, что если модуль уязвимости выбран без входных данных (например, случайно выбран из всех уязвимостей), входные данные для параметров этого модуля могут быть сгенерированы автоматически.
    
    Например:
    
    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>
    

Обратите внимание, что сценарий может выбирать и пропускать определенные параметры:

scenario.xml:```xml  LEAK THIS!

root@kitploit:~
    
    
    В приведенном выше случае параметр "some_random_setting" примет свое значение по умолчанию (["true"]), а утекшие строки будут значением из сценария (["LEAK THIS!"]).
    
    Значения параметров могут быть случайным образом выбраны с помощью модуля кодировщика случайного выбора. Например:
    
    secgen_metadata.xml:```xml
    <default_input into="some_random_setting">
      <encoder name="Random String Selector">
        <value>true</value>
        <value>false</value>
      </encoder>
    </default_input>
    

В результате каждый раз при использовании модуля он будет случайным образом сконфигурирован, если только это явно не указано в сценарии.

Входные данные по умолчанию также могут быть сконструированы с помощью сложных вложенных генераторов и кодировщиков:

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>

root@kitploit:~
    
    
    ### Puppet-файлы
    Каждый модуль уязвимости, сервиса и утилиты содержит Puppet-файлы, которые используются для установки программного обеспечения на виртуальные машины.
    
    Каталог модуля содержит
     - Puppet-модуль
     - точку входа Puppet (имя файла совпадает с именем каталога модуля, расширение .pp)
    
    Этот пример должен помочь пояснить. Distcc имеет документированную уязвимость безопасности, позволяющую удаленное выполнение кода. Приведенный ниже пример взят из modules/vulnerabilities/misc/distcc_exec.
    
    Каталог manifest/ содержит Puppet-файлы для класса Puppet distcc_exec.
    
    В соответствии с соглашением, один файл для установки:````
    class distcc_exec::install{
      package { 'distcc':
        ensure => installed
      }
    }
    

Один файл для конфигурации (плюс файл шаблона):```` 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') } }

root@kitploit:~
    
    
    Один файл для обеспечения запуска сервиса:````
    class distcc_exec::service{
      service { 'distcc':
        ensure => running
      }
    }
    

Пока что это всё типичный Puppet.

Наконец, добавляем точку входа модуля с тем же именем, что и каталог .pp:```` include distcc_exec::install include distcc_exec::config include distcc_exec::service

root@kitploit:~
    
    
    Чтобы узнать больше о Puppet и понять, как писать модули, посмотрите SecGen Wiki, а также http://puppetlabs.com/
    
    ### local/secgen_local.rb
    
    Кодеры и генераторы имеют код, который выполняется во время сборки проекта, например, кодирование текста, создание флагов и другого содержимого. В каждом случае это ruby-скрипт, расположенный в каталоге модуля в local/secgen_local.rb. Хотя обычно он вызывается SecGen, скрипты secgen_local.rb могут выполняться напрямую и принимать все входные параметры в качестве аргументов командной строки, а вывод возвращать в формате JSON в stdout. Другой читаемый человеком вывод направляется в 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="]
    ```
    ![гифка-прелесть](https://assets.kitploit.com/production/public/readmes/39158/43bb231998f6f132f11c5802c09885b34eb72955300c3046d41edbfffa938437.gif "скрипты secgen_local.rb могут быть выполнены напрямую")
    ![гифка-прелесть](https://assets.kitploit.com/production/public/readmes/39158/db9c2d10f6832ac2e5a7d63789d80251644028c871002e3efc74ff7917527576.gif "Программирование генератора или кодировщика — это просто!")
    
    ## Вывод проекта SecGen
    По умолчанию вывод осуществляется в projects/SecGen_[CurrentTime]/
    
    Вывод проекта включает в себя:
     - Конфигурация Vagrant для развертывания виртуальных машин.
     - Каталог, содержащий все необходимые модули Puppet для вышеуказанного. Создается файл Librarian-Puppet для управления модулями, и некоторые требуемые модули могут быть получены через PuppetForge, поэтому при создании проекта требуется подключение к Интернету.
     - Дерандомизированный файл сценария XML. Используя SecGen, вы можете повторно использовать этот файл scenario.xml для воссоздания вышеуказанной конфигурации Vagrant и файлов Puppet. В этом выводе любая примененная рандомизация должна быть дерандомизирована (по сравнению с исходным файлом сценария). Этот файл содержит все детали созданных систем и также может быть использован позднее для оценки, подсчета очков или предоставления подсказок.
     - Файл marker.xml, полезный для CTF-мероприятий, содержащий все флаги вместе с множеством подсказок для каждого флага. Он может быть использован для настройки фронтенда CTF.
    
    Если вы запускаете SecGen с командой "build-project" (или "p"), он создает вышеуказанные файлы и затем останавливается. Команда "run" (или "r") создает файлы проекта, а затем использует Vagrant для сборки виртуальных машин.
    
    Есть возможность скопировать каталог проекта на любую совместимую систему с Vagrant и просто выполнить "vagrant up" для создания виртуальных машин.
    
    Пароль root по умолчанию для базовых образов — 'puppet', но он может быть изменен SecGen в зависимости от используемого сценария.
    
    ## План развития
    - **Больше модулей!** Включая больше модулей в стиле CTF.
    - Базовые образы Windows и уязвимости.
    - Вывод (рандомизированных) лабораторных работ по безопасности с рабочими листами.
    - Облачное развертывание.
    - Дальнейшая геймификация и иммерсивные сценарии.
    
    ## Благодарности
    *Команда разработчиков:*
    - Dr Z. Cliffe Schreuders http://z.cliffe.schreuders.org
    - Tom Shaw
    - Jason Keighley
    - Lewis Ardern — автор первой концептуальной версии SecGen
    - Connor Wilson
    
    Большое спасибо всем, кто внес вклад в проект. Вышеуказанный список неполный или исчерпывающий, пожалуйста, обращайтесь к [истории GitHub](https://github.com/cliffe/SecGen/graphs/contributors).
    
    Этот проект поддерживается грантом Higher Education Academy (HEA) по обучению и преподаванию в области кибербезопасности (2015–2017).
    
    ## Участие в разработке
    Мы призываем к участию в проекте, пожалуйста, обратитесь к вики за руководством по внесению вклада.
    
    Кратко: сделайте форк из http://github.com/cliffe/SecGen/, создайте ветку, внесите изменения, закоммитьте их, а затем создайте пул-реквест.
    
    ## Ресурсы
    Статья: [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) (Эта статья дает хороший обзор SecGen.)
    
    Статья: [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) (В этой статье описывается первый прототип.)
    
    Интервью в подкасте: [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/)