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

Не успел я в прошлой "Колонке редактора" вспомнить про Microsoft и их наработки в области безопасности, как в Москву прилетел Стив Липнер. Это удивительный человек. Сложно представить, но свой первый отчет об уязвимостях в программном обеспечении он написал 40 (!) лет назад. Сейчас Стив работает в Microsoft и отвечает за стратегию безопасности разработки ПО, в основе которой лежит принятая компанией в 2004 году политика SDL (Security Development Lifecycle).

По сути, SDL — это набор практик, проверенных временем подходов и инструментальных средств, которые позволяют разрабатывать безопасный код. Мы уже рассказывали об этой концепции в материале "SDL, или безопасность по Microsoft" пару лет назад, и сейчас не будем подробно на этом останавливаться. Так что, когда я буду упоминать этот термин, можно воспринимать его просто как набор правильных требований и рекомендаций от профессионалов.

Особый интерес во время знакомства с SDL для меня представляли конкретные инструменты для безопасного написания кода и тестирования приложения на наличие уязвимостей. Многие из них вышли из недр внутреннего использования Microsoft и стали публично доступными. Но самое главное, что их может использовать каждый из нас, прямо с сегодняшнего дня. Большинство из утилит пригодятся не только разработчикам, но и вообще всем, кто занимается информационной безопасностью. Меня приятно удивили слова Стива, который рассказал, что за последние два года их стало гораздо больше. Я обобщил наш разговор и подготовил для тебя подборку как раз таких инструментов, разбив их на несколько тематических разделов.

Info

Подробная информация и файлы всех упомянутых утилит можно найти на официальном сайте Secure Lifecycle Development: microsoft.com/security/sdl.

Анализ бинарников/сборок

BinScope Binary Analyzer

Недаром мы уделяем много времени обходу защит DEP и ASLR. Это действительно серьезный барьер для создателей сплойтов, который кардинальным образом влияет на возможность эксплуатации найденной уязвимости. Чтобы понимать, что представляют собой требования SDL, вот в качестве примера одно из них: "Любое приложение должно быть в обязательном порядке защищено как DEP, так и ASLR". Для этого исходник должен быть собран соответственно с флагами /NXCOMPAT и /DYNAMICBASE. Но это лишь одно из требований, а с помощью анализатора Binscope SDL можно выяснить, использует ли приложение все рекомендации и требования SDL. Программа проверяет, были ли установлены требуемые правилами SDL флаги компилятора/сборщика, использовались ли самые последние версии инструментария и так далее. Помимо этого Binscope сообщает об использовании опасных конструкций, который являются запрещенными или нежелательными (к примеру, использование указателей на глобальные функции).

AppVerifier

Application Verifier — это тоже анализатор, но предназначен для динамического исследования native-кода и обнаружения программерских ошибок, которые сложно отловить во время обычной процедуры тестирования приложения. Динамический подход подразумевает, что программа анализируется прямо во время ее выполнения (это называется runtime-тестированием). AppVerif отслеживает работу программы и проверяет, не выполняет ли оно действий, опасных с точки зрения безопасности. Например, если исследуемое приложение создаст объект без дескриптора безопасности или небезопасным образом передает параметры в API, то выдается предупреждение.

Attack Surface Analyzer Beta

Определение поверхности атаки — задачка для Attack Surface Analyzer. Это один из самых последних инструментов из лаборатории Microsoft, о котором я рассказывал в "Колонке редактора" прошлого номера. Анализатор позволяет отследить изменения в системе, произошедшие в результате каких-то определенных действий. Например, сделав snapshot’ы до и после установки исследуемого приложения и сравнив их, можно определить все произошедшие изменения: появление новых файлов, ключей реестра, сервисов, ActiveX-компонентов, открытых портов, изменения в ACL-списках и так далее.

Анализ кода

Code Analysis for C/C++

Автоматизированное исследование исходных кодов на наличие признаков уязвимостей называется статическим тестированием. В свою очередь, Code Analysis for C/C++ является стандартным статическим анализатором кода и по умолчанию входит в состав некоторых редакций Visual Studio. Продуманные механизмы позволяют автоматизировать поиск в native-коде утечек памяти, неотловленных исключений, проблем с быстродействием и, конечно же, уязвимостей в области безопасности.

Microsoft Code Analysis Tool .NET (CAT.NET)

Это тоже утилита для статического анализа, но упоминание .NET в названии программы неслучайно: она производит анализ управляемого кода (C#, Visual Basic .NET, J#). Основная специализация — веб-приложения. CAT.NET выявляет слабые места, которые могут быть впоследствии эксплуатированы через такие векторы атак как Cross-Site Scripting (XSS), SQL Injection и XPath Injection. До публичного релиза это был исключительно внутренний инструмент в компании Microsoft.

FxCop

Это тоже статический анализатор управляемого кода. По сути, он проверяет сборки .NET на соответствие рекомендациям по проектированию библиотек .NET Framework. Правда, он тестирует не исходник, а компилированный объектный код. FxCop использует разбор CIL (промежуточный язык, разработанный Microsoft для платформы .NET) и анализ графа вызовов для проверки сборок на наличие более чем двухсот различных дефектов.

Библиотеки

Anti-Cross Site Scripting (Anti-XSS) Library

Многие из уязвимостей можно заранее предупредить, если предложить разработчикам соответствующие инструменты. К примеру, Anti-XSS разработана специально для того, чтобы уменьшить вероятность осуществления XSS-атак на веб-приложения. Важно, что решение включает в себя что-то вроде WAF (файрвол для веб-приложения) — так называемый Security Runtime Engine (SRE). Это движок, запущенный в виде HTTP-модуля, который обеспечивает дополнительный уровень защиты для веб-приложения без необходимости перекомпилирования.

SiteLock ATL Template

Если ты читал статью Алексея Синцова "Глумимся над объектами: взлом ActiveX", то должен хорошо понимать, чем грозят ошибки в ActiveX-компонентах. Библиотека SiteLock Active Template не поможет избавиться от оставленных в коде багов, зато на порядок снизит риск их эксплуатации. Дело в том, что с помощью ATL можно ограничить запуск ActiveX-компонентов, используя заранее определенный список доменных имен и зон безопасности. Можно сделать так, чтобы ActiveX-компонент выполнялся только в интранете (то есть в локальной сети), но не работал на страничках в интернете. Ограничивая возможности по эксплуатации уязвимостей, мы заметно снижаем поверхность возможной атаки.

banned.h

Если говорить о разработке на C/C++, то особый риск в коде представляют команды, позволяющие выполнить buffer overflow и другие похожие типы атак. Таких команд очень много: функции для работы со строками (xstrcpy(), strcat(), gets(), sprintf(), printf(), snprintf(), syslog()), системные команды (access(), chown(), chgrp(), chmod(), tmpfile(), tmpnam(), tempnam(), mktemp()), а также команды системных вызовов (exec(), system(), popen()). Вручную исследовать весь код (особенно если он состоит из нескольких тысяч строк) довольно утомительно. Это проверяют статические анализаторы, но есть еще один вариант — использовать специальный заголовочный файл, который не допустит использования функций, давно не рекомендуемых к использованию (и, естественно, запрещенных SDL).

Проектирование

SDL Threat Modeling Tool

Важной частью проектирования будущего программного продукта является моделирование угроз. Результатом моделирования является схема основных элементов будущей системы и обозначенные на ней границы доверия. Так вот SDL Threat Modeling Tool позволяет экспертам в области, не связанной с безопасностью, создавать и анализировать модели угроз. Используя полученные диаграммы, можно распознать возможную опасность и выполнить ее смягчение. SDL Threat Modeling Tool сама предлагает подсказки во время построения диаграмм и указывает на возможные просчеты.

SDL Process Template

Для Visual Studio (что неудивительно) доступен специальный шаблон, который автоматически интегрирует политику, процесс и средства, связанные с руководством по процессу Microsoft SDL непосредственно в среду разработки. Таким образом, создавая проект на основе этого шаблона, придется выполнять все условия SDL. И это очень правильно.

Фаззеры

MiniFuzz File Fuzzer

Согласно SDL, в качестве одного из обязательных этапов проверки приложения (на стадии верификации) должен использоваться фаззинг, то есть тестирование случайными входными данными. Minifuzz File Fuzzer — основное средство нечеткого тестирования, разработанное для упрощения поиска проблем, которые могут привести к уязвимости системы безопасности в коде обработки файлов. Тулза генерирует различные варианты содержания файла и "скармливает" его приложению, пытаясь выявить необрабатываемые исключения.

SDL Regex Fuzzer

Средство нечеткого тестирования регулярных выражений (Regex) — это еще один фаззер, который опубликовала Microsoft. SDL Regex Fuzzer позволяет выполнять проверку регулярных выражений на наличие потенциальных уязвимостей типа "отказ в обслуживании". Это неспроста. Регулярные выражения (особенно в нагруженных участках кода) нужно использовать очень аккуратно. Регулярные выражения, содержащие паттерны, которые выполняются за экспоненциальное время (например, повторение фрагментов, которые сами являются повторяющимися), могут быть использованы злоумышленниками для осуществления DoS-атаки. Фаззер, в свою очередь, позволяет прямо во время разработки выявить возможные уязвимости в регекспах.