Solar appScreener — российский статический анализатор кода приложений на наличие уязвимостей и НДВ. Его преимуществом является возможность анализа не только исходного, но и бинарного кода (представленного в виде исполняемых приложений). Реализована поддержка 20+ языков программирования и 7 форматов исполняемых файлов, в том числе для Google Android, Apple iOS и Apple macOS.
- Введение
- Виды анализа защищенности приложений
- Бинарный анализ или технология анализа исполняемых файлов
- Реализация бинарного анализа в Solar appScreener
- Выводы
Введение
По оценкам антивирусной компании McAfee, общемировой ущерб от киберпреступлений в 2017 году составил около $600 млрд, что эквивалентно 0.8% мирового ВВП. Мы живем в век технологического бума, спецификой которого стала стремительная интеграция всемирной сети и интернет-технологий во все сферы жизни человека. Сейчас киберпреступления уже не являются чем-то из ряда вон выходящим. Данные статистики демонстрируют рост киберпреступности в геометрической прогрессии.
Уязвимость приложений превратилась в серьезную проблему: по данным Министерства внутренней безопасности США, более 90% успешных кибератак реализуется с использованием различных брешей в приложениях.
Рисунок 1. Уязвимости — основа 90% успешных кибератак
Самыми известными способами эксплуатации уязвимостей являются:
- внедрение SQL-кода,
- переполнение буфера,
- межсайтовый скриптинг,
- использование небезопасной конфигурации.
Виды анализа защищенности приложений
Анализ программного обеспечения (ПО) на наличие недекларированных возможностей (НДВ) и уязвимостей на сегодняшний день является основным средством, позволяющим обеспечить безопасность приложения.
Говоря о классических и устоявшихся технологиях анализа ПО на уязвимости и НДВ (на предмет соответствия требованиям ИБ), можно выделить:
- Статический анализ кода (Static Application Security Testing)
- Динамический анализ кода (Dynamic Application Security Testing)
Рисунок 2. DAST vs SAST
Динамический анализ (метод «Черного ящика») представляет собой проверку программы на наличие уязвимостей непосредственно во время ее выполнения. У этого подхода можно выделить следующие преимущества:
- Так как уязвимости находятся в исполняемой программе и обнаружение ошибки происходит с помощью ее эксплуатации, то генерация ложных срабатываний меньше, чем у статического анализа.
- Для выполнения данного вида анализа не нужен исходный код.
Недостатками метода являются:
1. Неполное покрытие кода, в связи с чем существуют риски пропущенных уязвимостей. Покрытие кода является неполным, так как не все участки кода могут быть доступны в процессе исполнения программы на конкретном наборе выходных данных.
2. Необходимость максимально точного воспроизведения боевой среды при тестировании. При полном воспроизведении боевой среды реальные данные пользователей будут скомпрометированы, поэтому при динамическом тестировании приходится делать ряд допущений, что приводит к потере качества сканирования.
Статический анализ (метод «Белого ящика») представляет собой тип тестирования программы, при котором, в отличие от динамического анализа, не происходит выполнение программы.
Преимуществами этого вида анализа считаются:
- Полное покрытие кода, что приводит к поиску большего количества уязвимостей.
- Отсутствие зависимости от среды, в которой будет производиться выполнение программы.
- Возможность внедрения тестирования на соответствие требованиям ИБ на начальных этапах написания кода модуля или программы при отсутствии исполняемых файлов, что позволяет уже на старте разработки гибко интегрировать подобное решение в SDLC (Software Development Life Cycle — жизненный цикл разработки ПО).
Единственным недостатком метода является наличие ложноположительных срабатываний — необходимость оценки, указывает ли анализатор на реальную ошибку, или есть вероятность, что это срабатывание ложное.
Очевидно, у обоих методов анализа есть как преимущества, так и недостатки, однако возможно ли каким-либо образом использовать плюсы этих методов, минимизируя при этом недостатки? Да, если применить технологию бинарного статического анализа — статического анализа исполняемых образов программ.
Бинарный анализ, или технология анализа исполняемых файлов
Бинарный анализ позволяет проверять приложение на наличие уязвимостей, даже когда разработка уже закончена и нет доступа к его исходному коду, например, в случае использования кода сторонних подрядчиков. При этом покрытие кода будет полным, в отличие от применения метода динамического анализа. Также с помощью бинарного анализа можно осуществить проверку использованных в процессе разработки сторонних библиотек. Кроме того, бинарный анализ дает возможность сканировать приложения из Google Play и App Store.
Рисунок 3. Перевод исполняемых файлов в исходный код
За счет чего достигаются вышеуказанные преимущества?
Дело в том, что в процессе бинарного анализа происходит преобразование бинарного образа в промежуточное представление (внутреннее представление) для дальнейшего анализа. После этого к внутреннему представлению применяются алгоритмы статического анализа. В результате происходит дополнение текущей модели информацией, необходимой для дальнейшего обнаружения уязвимостей и НДВ. На следующем этапе к дополненной модели применяются правила поиска уязвимостей и НДВ.
Для специалиста, занимающегося анализом, важно отображать уязвимости и НДВ, найденные в бинарном коде, на исходный код. Для этого на завершающем этапе запускается процесс деобфускации (распутывания) в том случае, если были применены запутывающие преобразования (обфусцирующие), и декомпиляции (восстановления) бинарного кода в исходный.
Однако при реализации бинарного анализа возникают определенные сложности и свои «подводные камни», которые следует учитывать и с которыми нужно отдельно работать.
При бинарном анализе необходимо восстанавливать потерянную при компиляции информацию, чтобы найти уязвимости и НДВ. Также необходимо восстанавливать участки исходного кода с уязвимостями, так как принимать решения по исправлению уязвимостей в бинарном и байт-коде проблематично. Задачи восстановления информации, а впоследствии и исходного кода, являются алгоритмически сложными, поскольку ряд преобразований при компиляции являются необратимыми.
Если в процессе написания кода была применена обфускация, значит, при бинарном анализе придется прибегнуть к процедуре деобфускации. Здесь следует учитывать, что запутывающие преобразования могут применяться на любой стадии компиляции. Они сохраняют функциональность исходного кода, но затрудняют декомпиляцию полученного бинарного образа. То есть анализ таких бинарных образов будет затруднен.
Информация отладки (debug info) существенно упрощает декомпиляцию и деобфускацию. Debug info дает важную информацию, которая может быть использована во время поиска уязвимостей и НДВ в бинарном коде, отладке программы и разного рода отказах. Однако в большинстве случаев, когда необходимо применение бинарного анализа, debug info отсутствует.
Таким образом задача бинарного анализа нетривиальна, а ее решение требует сложных наукоемких алгоритмов статического анализа и обратной трансляции. Данный вид анализа пока реализован лишь в паре из представленных на мировом рынке решений. И лишь в одном из них — без опоры на debug info.
Реализация бинарного анализа в Solar appScreener
Solar appScreener автоматически определяет язык приложения, переданного на анализ. В настоящее время решение осуществляет бинарный анализ приложений на языках программирования Java, Java for Android, Scala, Kotlin, C/C++, Objective-C, Swift. Кроме того, Solar appScreener поддерживает статический анализ исполняемых файлов со следующими расширениями: .jar, .war, .dll, .exe, .apk, .ipa, .app. Продукт позволяет скачивать для анализа приложения по ссылкам из Google Play и App Store.
Рисунок 4. Схема работы бинарного анализа в Solar appScreener
Рассмотрим, как это реализовано на практике. Возьмем приложение с открытым исходным кодом из Google Play, например, веб-браузер lightning browser.
Рисунок 5. Lightning Web Browser в Google Play
У данного приложения почти 13 тысяч скачиваний, и оно имеет достаточно высокий рейтинг 4.1.
Рисунок 6. Отзывы о Lightning Web Browser
Но так ли все хорошо у данного приложения с уровнем безопасности программного обеспечения? Под уровнем безопасности ПО имеется в виду интегрированная оценка, выдаваемая анализатором Solar appScreener, которая может охарактеризовать, насколько надежно защищена программа. Система оценивает безопасность по шкале от 0 (плохо) до 5 (отлично). Данная оценка зависит от количества уязвимостей критического (больший вес) и среднего уровня и от объема кода. Давайте проверим этот показатель у выбранного приложения, проанализировав .apk файл с помощью бинарного анализа Solar appScreener.
Рисунок 7. Загружаем приложение в Solar appScreener
Анализатор Solar appScreener имеет простой и интуитивно понятный интерфейс, поэтому не нужно обладать какими-либо специальными навыками разработчика, чтобы запустить процесс анализа приложения. Для загрузки приложения из Google Play или App Store достаточно лишь скопировать ссылку в appScreener. Это позволяет начать сканирование в несколько кликов.
Рисунок 8. Обнаруженные уязвимости — обзор результатов
Что же произошло? Мы смогли проанализировать исполняемый .apk файл для Android из Google Play, не имея при этом исходных кодов.
Рисунок 9. Подробные результаты анализа
Solar appScreener находит уязвимости на уровне байт-кода и транслирует их на исходный код при помощи технологии декомпиляции. В итоге, загрузив .apk файл или ссылку на приложение в Google Play, на выходе мы получаем список уязвимостей, для которых корректно восстановлен исходный код. Рассмотрим наиболее критичные.
Рисунок 10. Android: нет проверки хоста сертификата
Обнаружено отсутствие процедуры проверки хоста сертификата. Переопределяется метод интерфейса verify, который всегда возвращает true. Таким образом, проверка подлинности домена в процессе проверки цепочки сертификатов отсутствует.
Рисунок 11. Android: небезопасная собственная реализация SSL (пустой метод)
В данном случае клиент принимает сертификат, не подписанный известным центром сертификации. В результате в приложении обнаружены тривиальные методы класса, отвечающего за проверку цепочки сертификатов, что делает приложение уязвимым к атакам типа man-in-the-middle («человек посередине»). Вообще, SSL разработан для более безопасной передачи информации с клиента на сервер. Данный протокол обеспечивает защиту от атак, основанных на прослушивании сетевого соединения. Например, от атак типа man-in-the-middle при условии, что будут использованы шифрующие средства, а сертификат сервера проверен и является надежным.
Возможный сценарий атаки с эксплуатацией данных уязвимостей выглядит следующим образом:
- Пользователь подключается к точке Wi-Fi, которая контролируется злоумышленником.
- Пользователь инициирует соединение с https://safeserver.example.com по протоколу SSL / TLS.
- Вместо открытого ключа https://safeserver.example.com злоумышленник передает приложению собственный открытый ключ и сертификат или сертификат, выданный ему центром сертификации для другого домена, например, https://hackedserver.example.com.
- Приложение убеждается в том, что полученный сертификат действителен (для https://hackedserver.example.com) или соответствует домену. При этом игнорируется факт того, что полученный сертификат либо выдан не для того домена, соединение с которым было запрошено изначально, либо он является самоподписанным.
Если говорить про результаты анализа приложения в целом, то, по нашим исследованиям, показатель 2.5 балла является средним для платформы Android. В действительности сложно однозначно судить о высокой или низкой степени защищенности того или иного приложения. Все познается в сравнении: например, для платформы Android средний уровень безопасности программного обеспечения составляет от 2.2 до 2.5 балла. Если уровень безопасности вашего приложения ниже 2.2, значит, оно несет в себе серьезные риски информационной безопасности. Если же ваш средний балл выше отметки 2.5, то, предположительно, ваше приложение неплохо защищено. Однако необходимо помнить, что даже одна уязвимость приложения может нести в себе серьезные риски, как репутационные, так и финансовые. Поэтому важно исправлять все участки уязвимого кода.
Просканируем еще одно приложение, на этот раз из App Store.
Рисунок 12. Скачиваем Brave Browser из App Store
Перейдем сразу к результатам сканирования. Прямо скажем, они выглядят впечатляюще: в приложении обнаружена 341 уязвимость критического уровня и 264 уязвимости средней степени критичности.
Рисунок 13. Обзор результатов сканирования Brave Browser на уязвимости
Рассмотрим уязвимости, имеющие самые большие шансы на эксплуатацию.
Рисунок 14. Objective-C: Небезопасные параметры SSL
Небезопасные параметры SSL. Для установления защищенного соединения приложение должно проверять:
- Соответствие полученного сертификата запрошенному хосту.
- Срок действия сертификата.
- Подтверждение того, что цепочка доверия ведет к одному из заданных в системе доверенных корневых сертификатов.
Отключение любого из параметров проверки может привести к компрометации передаваемых данных.
Рисунок 15. Objective-C: Слабый алгоритм хеширования
Данный вид уязвимости означает, что в приложении обнаружено использование небезопасного хеш-алгоритма (SHA-1). В случае его применения увеличивается вероятность того, что при наличии доступа к хешу пароля злоумышленник сможет подобрать слово, которому соответствует этот хеш, и использовать его в качестве пароля.
Рисунок 16. Objective-C: Использование NSLog
Метод NSLog чаще всего используется для отладки, и он не должен содержаться в финальной версии кода. Все выводимые посредством этого метода сообщения можно просмотреть с помощью среды разработки XCode, что может привести к раскрытию конфиденциальной или системной информации.
Как видно из данных примеров, бинарный анализ позволяет, не имея исходных кодов, успешно осуществлять обнаружение уязвимостей приложений. Уязвимости выявляются на уровне бинарного кода, при этом исходный код восстановлен для понимания уязвимости, что дает возможность проверить и исправить конструкцию на уровне исходного кода.
Кстати, Solar appScreener является единственным инструментальным средством статического анализа, которое может проанализировать бинарный код без debug info.
Рисунок 17. Результаты сканирования х86.exe
На рисунке 17 представлены результаты анализа .exe файла, просканированного Solar appScreener. Для данного файла не имелось в наличии debug info, но Solar appScreener справился с поставленной задачей. Рассмотрим несколько обнаруженных уязвимостей:
Рисунок 18. C/C++: Внутренняя утечка ценной информации
Данная уязвимость потенциально может привести к утечке информации о конфигурации системы. Злоумышленник может использовать эту информацию для разработки плана атаки. Отладочная информация и сообщения об ошибках в зависимости от настроек системы могут записываться в лог, выводиться в консоль или передаваться пользователю. В некоторых случаях злоумышленник по сообщению об ошибке может сделать вывод об уязвимостях системы. Например, ошибка базы данных может свидетельствовать о незащищенности от атак типа SQL injection. Информация о версии операционной системы, сервера приложений и конфигурации системы также могут представлять ценность для злоумышленника.
Рисунок 19. C/C++: Небезопасная функция rand
Приложение использует небезопасный генератор псевдослучайных чисел (ГПСЧ). Порождаемая последовательность чисел предсказуема. Примеры небезопасных ГПСЧ: rand, drand48, erand48, jrand48, lcong48, lrand48, mrand48, nrand48, rand_r, random. Злоумышленник, используя небезопасный ГПСЧ, может подобрать строку символов, соответствующую, например, паролю пользователя.
Выводы
Решение Solar appScreener успешно осуществляет анализ бинарного кода даже в отсутствии debug info, что отличает его от многих аналогичных средств анализа защищенности приложений. Ведь исходный код далеко не всегда имеется в наличии, а анализировать его необходимо. Важнейшей отличительной особенностью данного инструментального средства является возможность не только производить анализ приложений на наличие уязвимостей и выдавать результат, но еще и восстанавливать участок исходного кода, определяя в нем локализацию уязвимостей. При этом у разработчиков появляется реальная возможность исправлять такие уязвимости.
Итак, резюмируем возможности бинарного анализа, наглядно демонстрирующие его преимущества.
Во-первых, когда часть библиотек представлена в виде бинарного кода или байт-кода, бинарный анализ позволяет находить в них уязвимости.
Во-вторых, заказчики приложения могут проанализировать версию продукта, которая непосредственно находится в финальной стадии разработки, на боевом сервере. Эта возможность востребована в случае, если есть сомнения в добросовестности стороннего разработчика, который перед самым релизом может внедрить программную закладку. Или если по тем или иным причинам невозможно получить от разработчиков исходный код. Или же если есть подозрения в том, что заказчику могли прислать версию исходного кода, не соответствующую боевому серверу (актуально при использовании сторонней разработки).
Кстати, в конце января вышла новая версия Solar appScreener 3.0, в которой реализована полностью обновленная система взаимодействия продукта с пользователями. Значительным усовершенствованиям подвергся как графический интерфейс решения, который стал удобнее и современнее, так и функциональность системы.
Solar appScreener является российской разработкой, данное средство анализа кода сертифицировано ФСТЭК России.
Статья написана в соавторстве с Ярославом Александровым, руководителем группы разработки Solar appScreener.
