Безусловно, в данном случае логичнее анализировать исходные коды. Проводилось тестирование инструмента, обнаруживались уязвимости и закладки — то, что ищет инструмент.
Про методы и инструменты в статье описано — мы восстанавливаем модель кода, чаще всего это CFG (и описаны основные трудности восстановления), и далее применяем классические методы статического анализа — они, например, описаны в другой нашей статье. Можно описывать в деталях конкретные технические задачи — возможно, мы напишем несколько статей на эту тему.
Тут надо определиться с понятием «сложен для анализа». Сложность зависит в том числе от применяемых алгоритмов, а алгоритмы у разных анализаторов могут быть разные. Алгоритмы можно подстроить под конкретные язык, однако даже на одном языке можно писать код по-разному — сложнее или проще. Чем запутаннее программа, тем, потенциально, сложнее искать в ней уязвимости (опять же, в зависимости от метода). И тем сложнее восстановить конструкции исходного кода.
Мы проводили анализ своим инструментом одной из кодовых баз линукса, анализ прошел за несколько часов. Речь про автоматизированный анализ, с помощью такого анализа вполне можно провести сканирование с полным покрытием. Тут важно качество. Можно сделать анализ шаблонным поиском, однако вряд ли получатся качественные результаты. Далее чем сложнее алгоритмы, тем дольше идет анализ. В любом случае будет требоваться много железа и времени.
Точных оценок нет, сильно все зависит от конкретных структур в коде и от языка. Задача поиска уязвимости в общей постановке, безусловно, экспоненциально сложная. Задача алгоритмов статического анализа в том, чтобы решить задачу с хорошей точностью за адекватное время, потратив адекватное количество ресурсов.
В этом и есть ноу-хау продукта, что при отсутствии исходных кодов также проводится статический анализ, не динамический. Конечно, если бекдор заключается в мертвом коде, который удален при компиляции — не найдет. Но если речь идет о, например, триггере по времени, то бекдор вполне может быть найден с помощью реверс инжениринга. Скоро выйдет наша статья на эту тему здесь в блоге.
Речь об уязвимостях, которые обнаруживает статический анализатор. Безусловно, любой статический анализатор может давать ложные срабатывания (если он пытается находить интересные уязвимости). В этом смысле мы говорим про «потенциальные уязвимости». Разные анализаторы соревнуются по количеству ложных срабатываний и настоящих нахождений.
CVE — это все-таки база конкретных уязвимостей в конкретных системах и версиях, а тут мы анализируем переданный код. Можно обнаруживать, что в проекте используется уязвимая версия библиотеки, но это немного другой класс средств (SCA — software composition analysis). Критичность в анализаторах определяется экспертно в алгоритмической базе и в базе правил. Например, если алгоритм уверен в уязвимости, и это SQL-инъекция — будет критическое срабатывание. Если это плохая обработка ошибок — низкий уровень.
Генерировать SQL-запросы, действительно, можно так, чтобы проверить отсутствие SQL-инъекции было просто. Проблема в том, что существует очень много кода, написанного по-другому. И его надо анализировать.
Как правильно написано выше, анализатор может работать и на бинарниках, как, собственно, наш анализатор.
Про это мы немного писали в блоге, например про байткод Java и анализа iOS-приложений (раз и два).
Последнее время мы внедряем только наш анализатор, так что я предвзят:) Но пока заказчики не выкидывали его, все внедрения были успешные.
Внедрения очень разные, от ручного использования раз в месяц до интеграции в CI.
Из первого: мобильные приложения iOS и Android (два приложения, средние по размеру), заказчик примерно раз в месяц сканирует приложение по ссылке на Google Play и AppStore, ранжирует уязвимости, используя функционал инструмента, передает разработчикам уже финальный отчет для исправления.
Из второго: Java, 4.5 млн LOC, запуск из Jenkins раз в сутки. Внедрение шло 2 месяца, но в основном это связано с тем, что нужно было наладить организационный процесс (взаимодействие подразделений по использованию инструмента).
Думаю, мы напишем отдельную статью про опыт внедрения.
В некоторых случаях, действительно, разработчик может так сделать (использовать привязку параметров в SQL-запросе, например), и анализатору станет проще. Однако мы говорим про анализ случайного кода. Если анализатор будет просто проверять невыполнение контракта, на любом реальном проекте нормального размера будут сотни тысяч «уязвимостей», этим будет нереально пользоваться.
Не очень понятно, почему многие говорят про применение именно методов формальной верификации к этой задаче — далеко не всегда удобно составлять спецификацию контракта. Ну и контракты будут становиться больше, и формальную верификацию станет сложнее применять на практике.
Более того, ощущение, что иногда, говоря про формальную верификацию, на самом деле говорят про статический анализ (алгоритмы, взятые из теории построения компиляторов и примененные к поиску уязвимостей, багов и т.п.). Тот же самый securify, по ощущениям, проводят обычный статический анализ (как минимум наряду с попытками формальной верификации).
Мы вот в SmartDec давно занимаемся инструментами статического анализа, и, применив к Solidity, увидели, что это хорошо работает. Сейчас готовим первый релиз инструмента и научную статью на тему, но инструмент показывает уже лучшие результаты, чем у Oyente, Securify и Remix.
По понятный причинам за рынком инструментов мы следим, и видим, что вендоры начали этим заниматься. Однако на данный момент для смарт контрактов как никогда нужен ручной аудит кода на безопасность, и лично я бы рассматривал инструмент как помощь в этом деле.
Реализация самописных алгоритмов может отслеживаться по побочным эффектам — например, использованию результатов работы таких алгоритмов. На практике скорее используют небезопасные стандартные алгоритмы, чем самописные, поэтому большая часть таких уязвимостей обнаруживается.
Безусловно, инструменты автоматического анализа кода — как статического, так и динамического — не могут выявить абсолютно всех проблем, особенно связанных с некоторыми логическими уязвимостями.
Для такого глубоко анализа лучше применять ручной аудит кода :)
Я не совсем точно выразился в предыдущем комментарии. Уязвимостью является использование небезопасных функций хеширования и шифрования (типа MD5 или DES) для работы с критичными данными (конфиденциальными данными, для генерации идентифицирующих значений).
Речь идет о программных конструкциях, которые могут нарушить информационную безопасность приложений. Класс уязвимостей ограничен только движком анализа и правилами поиска.
У нас обнаруживаются уязвимости типа «внедрение» (SQL Injection, XSS, Path traversal и так далее), вызовы небезопасных функций (например, хеширования и шифрования), другие шаблонные небезопасные конструкции (например, отключение проверки сертификатов с помощью X509TrustManager), участки, подозрительные на НДВ (или закладки) — всего более 150 различных уязвимостей для языка Java.
Точных оценок нет, сильно все зависит от конкретных структур в коде и от языка. Задача поиска уязвимости в общей постановке, безусловно, экспоненциально сложная. Задача алгоритмов статического анализа в том, чтобы решить задачу с хорошей точностью за адекватное время, потратив адекватное количество ресурсов.
CVE — это все-таки база конкретных уязвимостей в конкретных системах и версиях, а тут мы анализируем переданный код. Можно обнаруживать, что в проекте используется уязвимая версия библиотеки, но это немного другой класс средств (SCA — software composition analysis). Критичность в анализаторах определяется экспертно в алгоритмической базе и в базе правил. Например, если алгоритм уверен в уязвимости, и это SQL-инъекция — будет критическое срабатывание. Если это плохая обработка ошибок — низкий уровень.
Про это мы немного писали в блоге, например про байткод Java и анализа iOS-приложений (раз и два).
Внедрения очень разные, от ручного использования раз в месяц до интеграции в CI.
Из первого: мобильные приложения iOS и Android (два приложения, средние по размеру), заказчик примерно раз в месяц сканирует приложение по ссылке на Google Play и AppStore, ранжирует уязвимости, используя функционал инструмента, передает разработчикам уже финальный отчет для исправления.
Из второго: Java, 4.5 млн LOC, запуск из Jenkins раз в сутки. Внедрение шло 2 месяца, но в основном это связано с тем, что нужно было наладить организационный процесс (взаимодействие подразделений по использованию инструмента).
Думаю, мы напишем отдельную статью про опыт внедрения.
Более того, ощущение, что иногда, говоря про формальную верификацию, на самом деле говорят про статический анализ (алгоритмы, взятые из теории построения компиляторов и примененные к поиску уязвимостей, багов и т.п.). Тот же самый securify, по ощущениям, проводят обычный статический анализ (как минимум наряду с попытками формальной верификации).
Мы вот в SmartDec давно занимаемся инструментами статического анализа, и, применив к Solidity, увидели, что это хорошо работает. Сейчас готовим первый релиз инструмента и научную статью на тему, но инструмент показывает уже лучшие результаты, чем у Oyente, Securify и Remix.
По понятный причинам за рынком инструментов мы следим, и видим, что вендоры начали этим заниматься. Однако на данный момент для смарт контрактов как никогда нужен ручной аудит кода на безопасность, и лично я бы рассматривал инструмент как помощь в этом деле.
Безусловно, инструменты автоматического анализа кода — как статического, так и динамического — не могут выявить абсолютно всех проблем, особенно связанных с некоторыми логическими уязвимостями.
Для такого глубоко анализа лучше применять ручной аудит кода :)
У нас обнаруживаются уязвимости типа «внедрение» (SQL Injection, XSS, Path traversal и так далее), вызовы небезопасных функций (например, хеширования и шифрования), другие шаблонные небезопасные конструкции (например, отключение проверки сертификатов с помощью X509TrustManager), участки, подозрительные на НДВ (или закладки) — всего более 150 различных уязвимостей для языка Java.