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

Доклад Ярослава Александрова, Александра Чернова и Екатерины Трошиной (Solar Security) для PDUG-секции на PHDays 8.

Transcript

1. ОБНАРУЖЕНИЕ УЯЗВИМОСТЕЙ В ТЕОРИИ И НА ПРАКТИКЕ, ИЛИ ПОЧЕМУ НЕ БЫВАЕТ ИДЕАЛЬНОГО СТАТИЧЕСКОГО АНАЛИЗАТОРА к.ф.-м. н. Катерина Трошина Ярослав Александров к.ф.-м. н. Александр Чернов Solar Security
2. Статический анализ как неотъемлемая часть разработки надежного кода в том числе и по требованиям информационной безопасности 2 •Качественная разработка требует наличие статического анализатора кода. •Почему анализаторов много, а идеального все равно нет?
3. Статический анализатор: мифы и реальность • Фазы работы статического анализатора кода МИФ: Универсальное внутреннее представление для всех языков • Шаблонный анализ • Внутрипроцедурный анализ • Межпроцедурный анализ • Taint-анализ Если все проходы делать качественно и полноценно, то анализатор будет работать долго и требовать много памяти. Лексический анализ Синтаксический анализ Семантический анализ Внутреннее представление 3
4. Оптимизации работы статического анализатора 4 • Продвижение данных по внутреннему представлению • Оптимизационные преобразования для циклов и ветвления • отсекание маловероятных веток • редукция циклов input output 90% 10%
5. Ошибки обработки потока информации. 5 • Ошибки валидирования (injections, XSS) • Никому нельзя доверять • Утечка информации • Ничего нельзя сообщать • Ошибки аутентификации • Ошибки на границах модулей системы • Трудно отследить
6. Ошибки работы с памятью 6 • Ошибки выхода за границу (out of bounds) • Использование после освобождения (Use after free) • Двойное освобождение (Double free) • Обращение по нулевому указателю (Null pointer dereference) Примеры CVE-2014-0160 - ошибка в библиотеке openssl - потенциальная компрометация приватных ключей потребовала перевыпуска всех сертификатов и перегенерации паролей cve-2015-2712 - ошибка в реализации js в mozilla firefox - bounds check cve-2010-1117 - use after free в internet explorer - remotely exploitable cve-2018-4913 - use after free in Acrobat Reader - code execution
7. Race condition и другие уязвимости “state machine” 7 • Сложности обнаружения в статике, так как нет понятия «времени». • Параллелизм везде и повсюду.
8. Ограничения в работе статического анализатора. 8 • Дефицит по памяти. • Дефицит по времени работы. • Ложные срабатывания. • Пропущенные ошибки. Статическим анализатором НАДО пользоваться
9. Использование статического анализатора 9 • Недостатки инструментов SAST • Теоретические ограничения алгоритмов статического анализа • Ограничения функциональности существующих инструментов • Инструменты надо использовать, но • существуют проблемы анализаторов на практике • Решение проблем со стороны анализатора • Нельзя решить все проблемы, но можно двигаться в эту сторону • Решение проблем со стороны пользователя • Как правильно использовать существующие инструменты?
10. Ложные срабатывания и длинные отчеты 10 • «Ложность» срабатывания может пониматься по-разному • Анализатор может помогать сортировать уязвимости по вероятности ложности • Разделение библиотек и собственного кода • SCA: software composition analysis • Фильтрация по файлам и по правилам • Отслеживание уязвимостей между сканированиями (устойчивое) • Первый отчет – значительное время (в том числе библиотеки) • Дальнейшие затраты – вопрос эффективности использования инструмента
11. Пропуски существующих уязвимостей 11 • Поиск уязвимостей • Ядро – алгоритмы анализа (может быть не реализован «движок») • Правила поиска уязвимостей (может быть не реализовано правило) • Алгоритмы, покрывающие доступные классы уязвимостей • Шаблонного поиска мало • Анализ потока управления, потока данных, … • Возможность добавлять пользовательские правила • Необходимо разобраться в причине пропуска уязвимости • По возможности дописать правило
12. Экспертиза для работы с инструментом 12 • Нужен эксперт для работы с инструментом • Специалист по информационной безопасности • Разработчик? • Удобный функционал инструмента • Понятные результаты анализа • Подробные описания с примерами, ссылками, рекомендациями по устранению, на разных языках • Трассы распространения данных • Для работы с инструментом нужно понимание разработки, но не очень глубокое
13. Запуск анализа 13 • Требования к формату файлов • Необходимая настройка сканирования (например, языки) • Требования к сборке • Максимально автоматизировать запуск сканирования • Настройки сканирования (например, языки) • Разбор переданного файла/директории • Максимально мягкие требования к сборке • Требовать артефакты, а не сборку на лету • Проводить частичный анализ без сборки • Разнообразные форматы: исходный код, бинарный код, ссылки • Правильно подготовить код (по документации) • При внедрении сложности со сборкой и конфигурированием решаются только один раз
14. Ресурсы 14 • Долго работает, потребляет много ресурсов (RAM, CPU) • Чем дольше работает и больше ресурсов, тем лучше качество • Сложно точно предсказать время и ресурсы • Архитектура, позволяющая отделять тяжелую часть • Выбор глубины анализа, легковесные проверки • Инкрементальный анализ • Вывод результатов в процессе анализа • Конфигурирование потребляемых ресурсов • Необходимо выделять нужные анализатору ресурсы
15. Интеграция в процесс 15 • Существуют налаженные процессы разработки, которые не хочется сильно менять • Полноценный неграфический интерфейс (CLI, REST API, …) • Готовые плагины к различным средствам • IDE (Eclipse, Visual Studio), системы сборки (maven, gradle) • Системы контроля версий (git, svn), сервера CI/CD (Jenkins, TeamCity) • Системы управления проектами (JIRA) и пользователями (AD) • Интеграция SAST в SDLC – наиболее эффективный способ использования • Технически – анализ после изменений кода или обновления анализатора • Организационно – разделение ролей разработчиков и специалистов ИБ, требования ИБ как часть ТЗ и приемки • Возможно ручное использование инструмента на разных стадиях разработки
16. Схема интеграции инструмента: пример 16 Developer IDE API commit Bug Tracking Build Tool Build Tool TestNG Test Environment VCS CI Team Lead Security Officer Results analysis Manager Analytics GUI scan MR→dev night build SAST TOOL
17. Заключение • Статический анализатор автоматически выявляет множество дефектов • Поддержка разработки, снижение концентрации уязвимостей в коде ОДНАКО • Нельзя полагаться только на статический анализатор • Наличие статического анализатора в процессе разработки не исключает требования к разработчикам по информационной безопасности • Критический по требованиям ИБ код должен проверяться экспертом вручную. Статический анализатор кода Грамотная команда разработчиков Эксперт по информационной безопасности 17 Успех вашего проекта
18. Заключение Все статические анализаторы плохие, если вы не умеете ими пользоваться 18
19. Спасибо!
20. Организация процесса разработки 20
21. Методология безопасной разработки 21 • SDL – Security Development Lifecycle (Microsoft) • Тестирование на соответствие требованиям информационной безопасности (ИБ) на всех этапах • Тестирование на соответствие требованиям ИБ независимыми по отношению к разработчикам экспертами в области информационной безопасности • Тестирование на соответствие требованиям ИБ с возможным наложением вето на выпуск релиза • Тестирование на соответствие требованиям ИБ после каждого внесения изменений в код или при обновлении базы правил поиска уязвимостей
22. Внедрение тестирования на соответствие требованиям ИБ 22 In-House Outsourcing Fixing cost Функционирующая система ~ 100 * X Приемка проекта ~ 10 * X Разработка проекта (ручной анализ) X Разработка проекта (непрерывная интеграция) X Исходный код Исполняемый код
23. Роли пользователей инструмента: пример 23 • Руководитель, менеджер • Динамика результатов сканирований проектов • Сравнение различных группы проектов • Технический руководитель проекта, специалист по информационной безопасности • Запуск сканирования через графический интерфейс • Работа с результатами сканирований • Динамика результатов в рамках проекта • Выгрузка pdf-отчетов по классификациям • Дополнительные правила поиска уязвимостей • Разработчик • Интерфейс командной строки, плагины к IDE • Подробные результаты сканирований
24. Схема интеграции инструмента: пример 24 Developer IDE API commit Bug Tracking Build Tool Build Tool TestNG Test Environment VCS CI Team Lead Security Officer Results analysis Manager Analytics GUI scan MR→dev night build SAST TOOL
25. После внедрения инструмента в SDLC 25 • Отлаженный процесс автоматического обнаружения уязвимостей, встроенный в непрерывный цикл разработки программного кода • Только «безопасные» релизы проектов • Снижение концентрации уязвимостей по всем проектам • Увеличение осведомленности разработчиков в области безопасной разработки