ВКР (1209243), страница 2

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

Текст из файла (страница 2)

Далее следует несколько отдалиться от места уязвимости и попытаться внедрить уязвимые данные в исследуемом месте (с помощью изменения содержимого памяти или регистров). Такой эксперимент покажет, есть ли возможность распространить данные из текущего места к уязвимому.

У эксперимента может быть два исхода: данные удалось переместить в необходимый раздел или же нет. Так определяется проходимость раздела.

4

Рисунок 1.5 – Перемещение вредоносных данных по разделам программы

Далее движение продолжается итеративно от уязвимого места к функции, принимающей пользовательский ввод, например WSARecv. Если найдена нужная цепочка разделов, то это гарантирует, что удастся организовать атаку.

Так же ручной поиск проводится при помощи банков угроз и уязвимостей. Исследователь учитывая свой опыт может сделать предположение о существование уязвимости в том или ином ПО и сверить его с банком угроз и уязвимостей.

Поиск по шаблонам

Поиск уязвимости по шаблону – автоматизированный метод, основанный на сравнении некоторых характеристик исследуемого ПО с заранее подготовленными описаниями (сигнатурами) уязвимых мест. Данный метод эффективен при поиске несложных уязвимостей и немаскируемых закладок, таких как переполнение буфера, парольные константы и т.д.

Поиск уязвимостей по шаблонам проводится статически. При статическом анализе исследуется код программы без его запуска. Код программного обеспечения (в большинстве случаев исходный) сравнивается с сигнатурами из базы методом побайтового сравнения или по более сложному алгоритму. При обнаружении сходств, сообщается о найденной уязвимости. Иногда сигнатура дополняется некоторым набором эвристических правил.

Современные сканеры кода позволяют хорошо стравляются с автоматизацией шаблонного поиска следующих типов уязвимостей:

• внедрение произвольных команд;

• SQL-инъекции;

• XSS-запрсоы (межсайтовый скриптинг);

• ошибоки входных и выходных значений;

• уязвимости переполнения буфера.

Поиску шаблонов уязвимого кода посвящены множество разработок: PREfast, lint, Parasoft, Coverity, FlawFinder, ITS4, RATS а так же продукты российского производства АК-ВС, и АИСТ-С. Все они поддерживают поиск ошибок в модулях исходного кода, написанных на одном из поддерживаемых языков.

Реже статический анализ проводится по исполняемому коду. К примеру, свободно распространяемая утилита FxCop от Microsoft проводит анализ объектного кода сборок .NET. С помощью анализа кода IL анализируется соответствие разработки стандартам кодирования, принятым Microsoft (SDL).

Чёрный ящик (Blackbox)

BlackBox – это поиск уязвимостей и векторов атак методом моделирования хакерской атаки. Аналитик, не имея никакой информации о системе, начинает эту информацию собирать.

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

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

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

Регулярные BlackBox-тестирования позволяют держать внешний периметр информационной системы в тонусе.

Нужно обратить внимание на регулярность, это действительно необходимо, потому что все информационные системы – живые организмы. Софт постоянно обновляется, администраторы постоянно что-то меняют, программисты выкатывают новые версии сайтов. И в дополнение ко всему – постоянно находятся новые уязвимости.

Белый ящик (White box)

WhiteBox – это более урожайный на уязвимости анализ. У аналитика изначально есть все исходные данные и он занимается их пристальным изучением.

Все работы делятся на три этапа:

• на первом этапе изучается окружение и вся информационная система целиком. На этом этапе определяются возможные угрозы, анализируется архитектура всей системы, изучаются настройки, проверяется соответствие элементов системы международным Benchmark’ам по безопасности;

• потом переходим к следующему этапу – это самое вкусное, в основном ради этого и делают такой анализ, анализ исходных кодов приложений. Тут анализируются собственные или заказные разработки.
  Сначала идут автоматические сканирования исходников статическими и динамическими анализаторами. Так же, происходит изучение всех зависимостей приложения на предмет устаревших версий, известных уязвимостей;

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

И в результате мы получаем максимально возможное количество уязвимостей, которые только можно найти в информационной системе. И, кроме уязвимостей, мы ещё получаем приятные бонусы:

• выявление бэкдоров, анализ архитектуры и логики приложений позволяет выявлять оставленные разработчиками бэкдоры;

• рекомендации по устранению уязвимостей, при анализе кода мы знаем не только как проявляют себя уязвимости, но и точное место где она возникали и почему, а это позволяет дать экспертные рекомендации: как их устранить и как не допускать их в будущем;

• PoC скрипты, для подтверждения уязвимостей и их автоматического воспроизведения мы можем написать скрипты. Обычное подтверждение уязвимости – это скриншот или набор входных данных, прикоторым можно воспроизвести и убедиться в наличии уязвимости. Но не все уязвимости можно подтверждать таким образом. Например, уязвимость по удалению базы пользователей. Деструктивное действие, которое мы не будем подтверждать на реальной системе. Но имея перед глазами исходник, мы можем написать нужный скрипт.

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

• тайное становится явным, даже если эксперты смогли обнаружить уязвимость только имея на руках исходный код – это не значит, что злоумышленники не смогут найти эти уязвимости;

• compliance, для соответствия требованиям некоторых отраслевых стандартов обязательно проводить тестирования WhiteBox или BlackBox;

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

Fuzzing (Серый ящик)

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

Часто подразумевается, что знание о тестируемом ПО получаются в ходе реверсивной инженерии. На основе полученных таким путем знаний планируется и выполняется ряд мероприятий по тестированию ПО - динамический анализ.

В последнее время приобретает популярность разновидность метода тестирования «серого ящика», которое получило название фаззинг (fuzzing). Термин не так давно вошел в обиход и поэтому присутствует далеко не во всех словарях. Самое близкое значения термина «анализ граничных значений» – определение доступных диапазонов входных значений программы и тестирование значений, которые выходят за этот диапазон либо находятся на границе. Фаззинг отличается тем, что не ограничивает свое внимание на граничных значениях, но так же занимается подготовкой входных данных специального вида.

Изначально фаззинг использовался для тестирования качества и отказоустойчивости ПО. В 1998 году проф. Бартон Миллер применил метод для тестирования приложений UNIX. И, несмотря на то, что поиск уязвимостей не был приоритетом тех исследований, исследования показали его пригодность в данных целях. Последний факт стал причиной популярности метода. Появились на свет множество коммерческих и свободно распространяемых продуктов для фаззинга: ProtosTestSuites, PROTOS SNMP, SPIKE, Mangleme, FileFuzz, SPIKEfile, Codenomican, COMRider, AxMan.

В зависимости от метода генерации данных принято разделять подход к фаззингу на два класса:

• мутация данных, новые данные получаются за счет незначительных изменений существующих данных;

• генерирование данных, данные подготавливаются «с нуля» на основе протоколов или в соответствие с заданными правилами.

Следующие типы фаззинга, так или иначе, относятся к одному из вышеперечисленных классов:

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

• использование случайных данных – это наименее эффективный из возможных подходов. Целевой программе передается большое количество случайных данных;

• ручное изменение данных протокола, исследователю известен протокол и он пытается добиться аномального поведения исследуемого ПО за счет внесения ошибочных данных. За счет отсутствия автоматизации мало эффективен;

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

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

По типу воздействия фазеры можно разделить на несколько классов: локальные, удаленные, в памяти и универсальные.

Локальные фаззеры делятся на следующие типы:

• фаззеры командной строки. Используются для выявления ошибок, связанных с разбором входных параметров программ;

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

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

Удаленные фаззеры бывают следующих типов:

• фаззеры сетевых протоколов. В зависимости от сложности протокола применяются фазеры соответствующей сложности;

• фазерыweb-приложений. Получили особую актуальность с развитием Web 2.0;

• фазерыweb-браузеров. Тестируется правильность разбора, как HTML-тэгов, так и других поддерживаемых расширений. Особо стоит выделить фазерыcom-объектов поддерживаемых браузерами.

Фаззинг в памяти напрямую воздействует на точки ввода данных в код, минуя средства доставки данных. Методика требует более детального разбора и по этой причине описана в отдельном пункте.

Под универсальными фаззерами здесь понимается инструментарий для быстрой разработки инструментов фаззинга (fuzzingframework). Такой инструментарий должен содержать в себе примитивы для генерации входных данных, а так же для их внедрения. На их основе может быть разработанфаззер необходимой конфигурации.

1.4 Инструментальные средства анализа защищённости

Согласно требованиям федеральных органов уполномоченных в области защиты информации для проведения анализа (контроля) защищённости должны использоваться только сертифицированные программные, технические и программно-технические средства.

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

Инструментальный анализ защищённости представляет собой автоматизированное тестирование на проникновение согласно той или иной модели нарушителя.

Для проведения полноценного анализа защищённости при помощи инструментальных используются следующее программы.

1. Программа фиксации и контроля исходного программного комплекса

Основные возможности таких программ:

• вычисление контрольных сумм заданных файлов по одному из пяти реализованных алгоритмов, в том числе ГОСТ Р 34.11-94;

• фиксация и последующий контроль исходного состояния программного комплекса;

• сравнение версий программного комплекса;

• фиксация и контроль каталогов;

• контроль различий в заданных файлах (каталогах);

• формирование отчетов в форматах TXT, HTML, SV.

Пример такой программы “ФИКС” с сертификатом ФСТЭК №1548 до 15 января 2020 г.

1. Программа контроля полномочий доступа к информационным ресурсам

Это программа контроля полномочий доступа к информационным ресурсам.

Основные возможности:

• сравнение структуры ресурсов АРМ, описанной в ПРД, с реальной структурой ресурсов;

• создание отчета по результатам сравнения;

• построение плана тестирования объектов АРМ;

• проверка реальных прав доступа пользователей к объектам доступа;

• создание отчета по результатам тестирования.

Пример: Ревизор 2 ХР с сертификатом ФСТЭК №990 до 08 февраля 2017 г.

1. Программа поиска и гарантированного уничтожения информации на дисках

Основные возможности таких программ:

• выбор диска для поиска ключевых слов;

• просмотр содержимого текущего диска;

• просмотр параметров текущего диска;

• сохранение фрагмента текущего диска в файл;

• копирование фрагмента текущего диска в буфер обмена;

• печать фрагмента текущего диска на принтере;

• сохранение образа текущего диска в файл;

• подключение образа диска, сохраненного в файл;

• формирование списков ключевых слов;

• выбор параметров поиска ключевых слов;

• поиск ключевых слов на диске;

• выборочное гарантированное уничтожение найденных ключевых слов;

• формирование отчета по результатам поиска;

• поиск файла, содержащего найденное ключевое слово;

• просмотр журнала событий программы;

• просмотр параметров лицензии программы.

Пример: TERRIER3.0 с сертификатом ФСТЭК №1193 до 16 мая 2018 г.

1. Сетевой сканер безопасности

Основные возможности таких программ:

• контроль изменений на сканируемых узлах;

• полная идентификация сервисов;

• определения типов и имен сервисов (HTTP, FTP, SMTP, POP3, DNS, SSH и др.) для определения настоящего имени сервера и корректной работы проверок;

• обработка RPC-сервисов (Windows и *nix) с полной идентификацией, включая определение детальной конфигурации компьютера;

• проверка слабости парольной защиты: оптимизированный подбор паролей практически во всех сервисах, требующих аутентификации;

• проведение проверок на нестандартные DoS-атаки;

• анализ структуры HTTP-серверов для поискa слабых мест в конфигурации;

• проверка узлов.

Пример: XSpiderс сертификатом ФСТЭК №3427 до 24 октября 2017

1. Программа инвентаризации ресурсов

Основные возможности таких программ:

• подбор паролей;

• сканирование сети;

• проведение детальной инвентаризации программного и аппаратно-технического обеспечение сети организации;

• поиск уязвимостей и критичных обновлений безопасности;

• детализированные отчёты;

• мониторинг сети.

Пример: RedCheck с сертификатом ФСТЭК №3172 до 23 июня 2017.

Довольно часто одно инструментальное средство может быть задействовано, как программный комплекс для проведения анализа защищённости (например, “Сканер - ВС”).

Характеристики

Список файлов ВКР