Доброго времени суток, коллеги!
Все из вас не раз сталкивались с проблемой анализа уязвимостей на целевой системе. Основным камнем преткновения которой является разрозненность подачи данных вендороми.
В одном месте вы можете найти саму уязвимость, в другом ее оценку, в третьем необходимые условия для проверки и в четвертом ссылку на патч.
Специально для решения этой проблемы существует язык описания уязвимостей OVAL
Данный язык стандартизирует способы подачи информации, процесс анализа системы и формат выдаваемого результата. Таким образом, мы получаете один XML файл, в котором уже описана уязвимость, метод определения, ссылка на патч, ссылка на CVE и многое другое. Так же, данный формат является стандартом для принятия информации для сканеров безопасности.
Сам по себе язык является довольно гибкой формализованной средой, позволяющей как использовать шаблонные конструкции, так и модифицировать их по своему вкусу. Таким образом, для подачи разнообразной информации используются одни и те же модели. С полным описанием языка можно ознакомиться в этом документе. Я же хочу вас познакомить с аспектами подачи информации об уязвимостях. А точнее, с конечным продуктом.
Окончательный вид, в котором вы получите данных об уязвимостях на языке OVAL будет в формате XML.
Для удобство понимания, будем рассматривать поподробнее на примере vulnerability OVAL для RedHat
Посмотрим же, что же мы найдем внутри.
Прежде всего то, что нам здорово поможет при автоматизации обработки OVAL-файлов, — схема и неймспейсы:
Это описание того, какие параметры и где нас будут ждать.
Далее идет блок, автоматически заполняемый генератором. Традиционное «что, где, когда»:
Дальнейшая информация делится на несколько больших смысловых блоков: definitions, tests, objects и states.
Definitions несет собственно саму информацию об уязвимости, в блоке tests описаны проверки, в разделе objects перечислены объекты проверок, а в части states описана формальное условие теста, применяющееся в объекты.
Для наглядности, давайте разберем построчно один элемент блока «definition»:
Основная информация подается в виде аттрибутов корневого тэга:
id=«oval:org.mitre.oval:def:975» — Идентификационный номер, уникальный в рамках данного неймспейса. Из него можно узнать, что это oval: созданный org.mitre.oval что это дефинишн :def: номер 975.
version=«2» — Версионная информация
class=«vulnerability» — класс дефинишена (в нашем случае это уязвимость, для патча это было бы «patch»)
Далее идет общая информация, отделенная тэгом .
Как видно из «говорящих» тэгов, это уязвимость «Red Hat OpenSSL do_change_cipher_spec Function Denial of Service»,
которой подвержен продукт OpenSSL в семейство ОС «unix» платформы Red Hat Linux 9.
Далее подается универсальное поле reference, в котором дается ссылка на CVE источник. Здесь может быть подана любая информация подобного типа (ссылка на bugzilla, к примеру).
Тэг тоже является легко-понимаемым и несет текстовое описание уязвимости.
Далее подается опциональная сервисная информация о репозитории <oval_repository>. Осноным его назначением является предоставление информации о смене статусов дефинишена. Ключевым полем является «status».
Следующий блок является самым «вкусным». Он несен в себе информацию о необходимых критериях и проверках для определения этой уязвимости, объединенных логическими условиями. Условием являются блоки criteria с параметром логического условия operator, которые могут быть вложенными. Таким образом, имея возможность отрицания (negate=«false»/«true»), операторы AND и OR мы имеем полноценную алгебру. При необходимости, здесь можно описать условие любой сложности. Ссылками на необходимый тест является блок criterion, указывающий на уникальный элемент типа «тест», содержащийся в данном OVAL файле.
Пройдет по такой ссылке, и посмотрим на него:
Как мы видим из содержания, это тест на факт установленного Red Hat 9.
Данную проверку необходимо выполнить хотя бы раз(«at least one») и проверить факт наличия такого объекта хотя бы в одном экземпляре («at_least_one_exists»).
Далее приводятся ссылки на объект и состояние, необходимые для положительного исхода. Данные блоки так же обязаны находиться в этом же репозитории OVAL.
Перейдем по ссылке на указанный объект:
И отсюда мы узнаем, что необходимо проверять версию redhat-release rpm.
Давайте же узнаем необходимые условия, — перейдем на указанный в тесте state:
И в описании вы видим, что необходимо сравнить версию RPM с 9. (9)
Таким образом, сложив по указанными в критериях условиям по логическим цепочкам мы получим необходимые условия для определения наличия уязвимости и выполнений условий дефинишена.
Надеюсь, на этом маленьком примере вам стал ясен способ подачи информации в OVAL-vulner.
Главный интерес формата заключается в его чрезвычайной гибкости. Для добавления дополнительных данных достаточно скорректировать схему и указать на нее ссылку. Но, о способах формирования этих файлов я расскажу Вам в другой раз.
Спасибо за чтение, надеюсь я рассказал Вам что-то новое.
Все из вас не раз сталкивались с проблемой анализа уязвимостей на целевой системе. Основным камнем преткновения которой является разрозненность подачи данных вендороми.
В одном месте вы можете найти саму уязвимость, в другом ее оценку, в третьем необходимые условия для проверки и в четвертом ссылку на патч.
Специально для решения этой проблемы существует язык описания уязвимостей OVAL
Данный язык стандартизирует способы подачи информации, процесс анализа системы и формат выдаваемого результата. Таким образом, мы получаете один XML файл, в котором уже описана уязвимость, метод определения, ссылка на патч, ссылка на CVE и многое другое. Так же, данный формат является стандартом для принятия информации для сканеров безопасности.
Сам по себе язык является довольно гибкой формализованной средой, позволяющей как использовать шаблонные конструкции, так и модифицировать их по своему вкусу. Таким образом, для подачи разнообразной информации используются одни и те же модели. С полным описанием языка можно ознакомиться в этом документе. Я же хочу вас познакомить с аспектами подачи информации об уязвимостях. А точнее, с конечным продуктом.
Окончательный вид, в котором вы получите данных об уязвимостях на языке OVAL будет в формате XML.
Для удобство понимания, будем рассматривать поподробнее на примере vulnerability OVAL для RedHat
Посмотрим же, что же мы найдем внутри.
Прежде всего то, что нам здорово поможет при автоматизации обработки OVAL-файлов, — схема и неймспейсы:
<oval_definitions xsi:schemaLocation="oval.mitre.org/XMLSchema/oval-definitions-5 oval-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-definitions-5#linux linux-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-common-5 oval-common-schema.xsd http://oval.mitre.org/XMLSchema/oval-definitions-5#unix unix-definitions-schema.xsd">
Это описание того, какие параметры и где нас будут ждать.
Далее идет блок, автоматически заполняемый генератором. Традиционное «что, где, когда»:
<generator>
<oval:product_name>The OVAL Repository</oval:product_name>
<oval:schema_version>5.10</oval:schema_version>
<oval:timestamp>2012-01-11T06:12:25.053-05:00</oval:timestamp>
</generator>
Дальнейшая информация делится на несколько больших смысловых блоков: definitions, tests, objects и states.
Definitions несет собственно саму информацию об уязвимости, в блоке tests описаны проверки, в разделе objects перечислены объекты проверок, а в части states описана формальное условие теста, применяющееся в объекты.
Для наглядности, давайте разберем построчно один элемент блока «definition»:
<definition id="oval:org.mitre.oval:def:975" version="2" class="vulnerability">
<metadata>
<title>Red Hat OpenSSL do_change_cipher_spec Function Denial of Service</title>
<affected family="unix">
<platform>Red Hat Linux 9</platform>
<product>OpenSSL</product>
</affected>
<reference source="CVE" ref_id="CVE-2004-0079" ref_url="cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0079"/>
<description>The do_change_cipher_spec function in OpenSSL 0.9.6c to 0.9.6k, and 0.9.7a to 0.9.7c, allows remote attackers
to cause a denial of service (crash) via a crafted SSL/TLS handshake that triggers a null dereference.</description>
<oval_repository>
<dates>
<submitted date="2004-03-20T12:00:00.000-04:00">
<contributor organization="The MITRE Corporation">Matt Busby</contributor>
</submitted>
<modified date="2004-05-05T12:00:00.000-04:00" comment="Corrected syntax errors in sql verion of the definition.">
<contributor organization="The MITRE Corporation">Matt Busby</contributor>
</modified>
<status_change date="2004-05-25T12:00:00.000-04:00">INTERIM</status_change>
<status_change date="2004-06-16T12:00:00.000-04:00">ACCEPTED</status_change>
<modified comment="Corrected regex to match only reasonable values for machine class.
Implemented by Jon Baker of the MITRE Corporation." date="2007-04-10T15:39:00.888-04:00">
<contributor organization="Maitreya Security">Thomas R. Jones</contributor>
</modified>
<status_change date="2007-04-10T15:41:24.326-04:00">INTERIM</status_change>
<status_change date="2007-04-25T19:53:11.788-04:00">ACCEPTED</status_change>
</dates>
<status>ACCEPTED</status>
</oval_repository>
</metadata>
<criteria comment="Software section" operator="AND">
<criterion comment="Red Hat 9 is installed" negate="false" test_ref="oval:org.mitre.oval:tst:3153"/>
<criterion comment="ix86 architecture" negate="false" test_ref="oval:org.mitre.oval:tst:3152"/>
<criterion comment="openssl version is less than 0.9.7a-20" negate="false" test_ref="oval:org.mitre.oval:tst:1484"/>
<criterion comment="openssl-devel version is less than 0.9.7a-20" negate="false" test_ref="oval:org.mitre.oval:tst:1483"/>
<criterion comment="openssl-perl version is less than 0.9.7a-20" negate="false" test_ref="oval:org.mitre.oval:tst:1482"/>
<criterion comment="openssl096 version is less than 0.9.6-25.9" negate="false" test_ref="oval:org.mitre.oval:tst:1481"/>
<criterion comment="openssl096b version is less than 0.9.6b-15" negate="false" test_ref="oval:org.mitre.oval:tst:1480"/>
</criteria>
</definition>
Основная информация подается в виде аттрибутов корневого тэга:
id=«oval:org.mitre.oval:def:975» — Идентификационный номер, уникальный в рамках данного неймспейса. Из него можно узнать, что это oval: созданный org.mitre.oval что это дефинишн :def: номер 975.
version=«2» — Версионная информация
class=«vulnerability» — класс дефинишена (в нашем случае это уязвимость, для патча это было бы «patch»)
Далее идет общая информация, отделенная тэгом .
Как видно из «говорящих» тэгов, это уязвимость «Red Hat OpenSSL do_change_cipher_spec Function Denial of Service»,
которой подвержен продукт OpenSSL в семейство ОС «unix» платформы Red Hat Linux 9.
Далее подается универсальное поле reference, в котором дается ссылка на CVE источник. Здесь может быть подана любая информация подобного типа (ссылка на bugzilla, к примеру).
Тэг тоже является легко-понимаемым и несет текстовое описание уязвимости.
Далее подается опциональная сервисная информация о репозитории <oval_repository>. Осноным его назначением является предоставление информации о смене статусов дефинишена. Ключевым полем является «status».
Следующий блок является самым «вкусным». Он несен в себе информацию о необходимых критериях и проверках для определения этой уязвимости, объединенных логическими условиями. Условием являются блоки criteria с параметром логического условия operator, которые могут быть вложенными. Таким образом, имея возможность отрицания (negate=«false»/«true»), операторы AND и OR мы имеем полноценную алгебру. При необходимости, здесь можно описать условие любой сложности. Ссылками на необходимый тест является блок criterion, указывающий на уникальный элемент типа «тест», содержащийся в данном OVAL файле.
Пройдет по такой ссылке, и посмотрим на него:
<rpminfo_test id="oval:org.mitre.oval:tst:3153" version="1" check="at least one" comment="Red Hat 9 is installed" check_existence="at_least_one_exists">
<object object_ref="oval:org.mitre.oval:obj:1414"/>
<state state_ref="oval:org.mitre.oval:ste:2949"/>
</rpminfo_test>
Как мы видим из содержания, это тест на факт установленного Red Hat 9.
Данную проверку необходимо выполнить хотя бы раз(«at least one») и проверить факт наличия такого объекта хотя бы в одном экземпляре («at_least_one_exists»).
Далее приводятся ссылки на объект и состояние, необходимые для положительного исхода. Данные блоки так же обязаны находиться в этом же репозитории OVAL.
Перейдем по ссылке на указанный объект:
<rpminfo_object id="oval:org.mitre.oval:obj:1414" version="1" comment="the redhat-release rpm">
<name>redhat-release</name>
</rpminfo_object>
И отсюда мы узнаем, что необходимо проверять версию redhat-release rpm.
Давайте же узнаем необходимые условия, — перейдем на указанный в тесте state:
<rpminfo_state id="oval:org.mitre.oval:ste:2949" version="1">
<version operation="equals">9</version>
</rpminfo_state>
И в описании вы видим, что необходимо сравнить версию RPM с 9. (9)
Таким образом, сложив по указанными в критериях условиям по логическим цепочкам мы получим необходимые условия для определения наличия уязвимости и выполнений условий дефинишена.
Надеюсь, на этом маленьком примере вам стал ясен способ подачи информации в OVAL-vulner.
Главный интерес формата заключается в его чрезвычайной гибкости. Для добавления дополнительных данных достаточно скорректировать схему и указать на нее ссылку. Но, о способах формирования этих файлов я расскажу Вам в другой раз.
Спасибо за чтение, надеюсь я рассказал Вам что-то новое.
