Анализ уязвимостей программного обеспечения в настоящее время является обязательным видом деятельности, выполняемым экспертами испытательных лабораторий отечественных систем сертификации средств защиты информации (СЗИ). Данный вид работ выполняется как при сертификации на соответствие требованиям профилей защиты, в которых в явном виде включены требования семейства доверия AVA_VAN «Анализ уязвимостей» (стандарты по линии «Общих критериев»), так и при испытаниях на соответствие требованиям технических условий или классических руководящих документов Гостехкомиссии России.

В настоящем исследовании представлена статистика выявления уязвимостей в программном обеспечении, которое было объектом сертификационных испытаний в Испытательной лаборатории НПО «Эшелон» в период 2016 — 2017 гг.

Методика исследования

Методика анализа уязвимостей, используемая испытательными лабораториями (ИЛ) в рамках сертификационных испытаний, базируется на «Общей методологии оценки» (международный стандарт ISO/IEC 18045) и в общем случае состоит из следующих этапов.

Этап 1. Выявление известных (подтвержденных) уязвимостей объекта сертификации. На данном этапе экспертами ИЛ осуществляется поиск известных (подтвержденных) уязвимостей в общедоступных источниках информации, например: в Банке данных угроз безопасности информации ФСТЭК России, ресурсах CVE, NVD, ресурсе разработчика программного обеспечения (ПО). Если информация об уязвимостях обнаруживается, то испытания приостанавливаются до момента передачи в ИЛ обновлений ПО, «закрывающих» известные уязвимости.

Этап 2. Выявление ранее не опубликованных уязвимостей объекта сертификации. На данном этапе эксперты ИЛ выполняют в общем случае следующие шаги:

• шаг 1: формирование перечня потенциальных уязвимостей объекта сертификации на основе изучения различных типов источников данных (проектная документация на объект сертификации, исходный текст, информация из открытых источников);
• шаг 2: создание тестовых сценариев (атак) для каждой идентифицированной потенциальной уязвимости;
• шаг 3: выполнение тестов с целью определения верности сделанного предположения.

В рамках данного исследования при выполнении шага 1 специалисты ИЛ НПО «Эшелон» использовали следующие методы формировании перечня потенциальных уязвимостей:

• экспертно-документальный метод, предусматривающий формирование перечня потенциальных уязвимостей на основе информации об известных уязвимостях в схожих по функциональным возможностям продуктах, в других версиях (например, более старых) объекта сертификации, в заимствованных компонентах, типовых уязвимостях, характерных для технологий, используемых при разработке объекта сертификации;
• статический анализ исходных текстов ПО (в случае предоставления доступа к исходным текстам в рамках сертификационных испытаний);
• фаззинг-тестирование.

При выявлении уязвимости в объекте сертификации подробная техническая информация предоставляется разработчику ПО с целью получения подтверждения сделанных экспертами ИЛ выводов и формирования мер по нейтрализации выявленной уязвимости (путем обновления ПО или определения указаний по эксплуатации). Предполагается, что выявляемые в ходе сертификационных испытаний/инспекционных контролей уязвимости должны проходить процедуру раскрытия через Банк данных угрозы безопасности информации ФСТЭК России.

Объекты исследования

Исследования проводились в период 2016 — 2017 гг. в рамках испытаний 76 продуктов по линии системы сертификации во всех системах сертификации (сертификационные испытания, инспекционные контроли) в ИЛ НПО «Эшелон».

Распределение исследованных продуктов по типам представлено на рис.1.


Рис.1. Распределение исследованных продуктов по типам
(СЗИ от НСД – средство защиты от несанкционированного доступа; ППО с СЗИ – прикладное программное обеспечение со встроенными средствами защиты информации; МЭ – межсетевой экран; САВЗ – средство антивирусной защиты; СУБД – системы управления базами данных; ОС – операционная система; СОВ – система обнаружения вторжений)

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

В зависимости от критериев сертификации, определяемых потенциальной областью применения сертифицируемого продукта, экспертам ИЛ предоставлялся или не предоставлялся доступ к исходным текстам объекта сертификации (рис. 2).


Рис.2. Распределение исследованных продуктов в зависимости от доступа к исходным текстам

Результаты исследований
В результаты исследований специалистами ИЛ НПО «Эшелон» была выявлена 81 уязвимость (уязвимости были выявлены в 26 продуктах из 76 исследованных). Для всех выявленных уязвимостей ПО было получено подтверждение об их актуальности со стороны разработчика ПО, разработчиками ПО были приняты меры по устранению выявленных уязвимостей.
На рис. 3 показано распределение выявленных уязвимостей по степени критичности (оценка выполнялась по методике CVSS версия 3.0).

Рис.3. Распределение выявленных уязвимостей в зависимости от степени критичности


Наиболее популярным типом уязвимого ПО стало прикладное ПО со встроенными средствами защиты информации (рис. 4).


Рис.4. Распределение выявленных уязвимостей в зависимости от типа
исследованного ПО

Основными типами векторов успешных атак, которые были разработаны экспертами ИЛ с целью подтверждения актуальности уязвимости, стали (рис. 5):

• межсайтовое выполнение скриптов (CAPEC-63);
• межсайтовая подделка запросов (CAPEC-62);
• повышение привилегий, связанное с обходом функций безопасности (CAPEC-233);
• атаки, направленные на отказ в обслуживании (CAPEC-2);
• раскрытие критичной информации ПО в сообщениях об ошибках (CAPEC-54);
• инъекция SQL-кода (CAPEC-66).

Рис.5. Распределение выявленных уязвимостей в зависимости от типа вектора атаки

В категорию «Иное» попали такие типы векторов атак, как: удалённое выполнение команд операционной системы путем передачи данных в HTTP-запросах (CAPEC-76), XML-инъекция (CAPEC-250), фиксация сессии (CAPEC-61), выход за пределы назначенной директории (CAPEC-126), атаки типа «Reparse-Point», «RegSafe/RegRestore».

Основными типами недостатков ПО, ставших причинами уязвимостей, стали (рис. 6):

• неверное использование данных, полученных из недоверенного источника, для генерации HTML-страницы (CWE-79);
• использование аутентификационных данных (данные cookie) для авторизации запроса (CWE-352);
• неверное использование данных, полученных из недоверенного источника, при выполнении функций безопасности (CWE-807);
• отсутствие авторизации при выполнении критичных операций (CWE-862);
• неверное использование данных, полученных из недоверенного источника, для генерации запроса к СУБД (CWE-89);
• неверная генерация сообщений об ошибках (CWE-209).

Рис.6. Распределение выявленных уязвимостей в зависимости от ошибки (недостатка) ПО

В категорию «Иное» попали такие типы ошибок ПО, как: использование заданных в коде программы аутентификационных данных (CWE-798), переполнение буфера (CWE-120), ошибки, приводящие к фиксации сессии (CWE-384), неверное использование данных, полученных из недоверенного источника, для генерации команд ОС (CWE-22) и пр.

Говоря о методах формирования перечня потенциальных уязвимостей, следует отметить, что большинство уязвимостей было обнаружено благодаря предположениям, сделанным на основе изучения документации на объект сертификации и данных об уязвимостях в схожих с объектом сертификации продуктах (рис.7).


Рис.7. Распределение выявленных уязвимостей в зависимости от метода формирования перечня потенциальных уязвимостей

Выводы

1. Надо признать, что доля уязвимостей, обнаруженных в ПО отечественного производства, несколько больше доли уязвимостей, обнаруженных в зарубежном ПО, даже на фоне существенной разницы между объемами исследованных продуктов отечественного и зарубежного производства. Думается, это объясняется существенными различиями в уровнях зрелости процессов жизненного цикла разработки безопасного ПО, внедренных у зарубежных и отечественных разработчиков ПО. Надеемся, с внедрением в стране стандарта по менеджменту безопасной разработке эта ситуация изменится.
   
   Следует отметить, что при проведении исследований для ПО зарубежного производства в большинстве случаев разработчиками не обеспечивался доступ к исходному коду объектов исследования, что делало принципиально невозможным формирование перечня потенциальных уязвимостей на основе исследования исходных текстов программы.
2. Большая часть выявленных в рамках исследования уязвимостей могла быть обнаружена разработчиками ПО на ранних стадиях разработки ПО с использованием анализа архитектуры ПО с точки зрения реализации угроз безопасности информации и статического анализа исходных текстов ПО.
3. С целью уменьшения количества уязвимостей разработчикам ПО рекомендуется внедрять в процессы жизненного цикла основные активности, направленные на разработку безопасного ПО (ГОСТ Р 56939) – анализ архитектуры ПО с точки зрения реализации угроз безопасности информации, статический анализ исходных текстов, тестирование безопасности. Внедрение подобных процедур в практику отечественных разработчиков ПО, на наш взгляд, повысить уровень защищенности создаваемого ПО и, как следствие, значительно уменьшить число инцидентов информационной безопасности.