Безопасно в смартфоне.

Исследование уязвимостей
мобильных приложений

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

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

Юрий Шабалин: Приложение, которое работает с push-уведомлениями.

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

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

Еще один пример – уязвимости в сервисе Remote Config. Это сторонний сервис, к которому при старте обращается приложение, чтобы удобно демонстрировать рекламу, спойлеры и так далее. Очень часто внутри этого сервиса хранятся ключи шифрования, ключи от интеграций, используя которые можно сильно навредить компании.

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

Юрий Шабалин: Если мы говорим про сегмент enterprise, то единственное средство динамического анализа для мобильных приложений – это «Стингрей». Если мы говорим про Open Sourсe, то существует много инструментов, которыми нужно уметь пользоваться, и в этом случае встает вопрос, связанный с кадровым голодом на ИБ-рынке.

Людей, которые хорошо разбираются в приложениях и умеют объяснить разработке, как их защитить, крайне мало, их необходимо растить, но не у всех компаний есть такая возможность.

Юрий Шабалин: Западные аналоги есть, но недоступны в России. В нашем случае ключевое преимущество в том, что это российское ПО, сделанное нашими руками, и мы никуда не уйдем. Второе – мы единственная компания, предоставляющая полноценную инсталляцию, то есть, «Стингрей» может работать в закрытом контуре. Плюс, если говорить о качестве проверок, скажу, что продукт основан на опыте инженеров, которые много лет работают на рынке защиты мобильных приложений.

Юрий Шабалин: Тут есть несколько критериев. Первое, что он должен делать – находить уязвимости качественно, что достигается за счет многообразия практик, которые создают полную картину.

Второе важное качество, которое должно быть у всех вендоров – сравнительно небольшое количество ложноположительных и ложноотрицательных результатов проверок.

Каждый вендор старается найти золотую середину между «не пропустить ничего» и большой массой ложных срабатываний. Мы пользуемся простой системой кастомизации инструмента под конкретное приложение, что позволяет сократить количество ложных срабатываний до минимума.

Последний важный критерий – это удобство интеграции в процесс разработки.

Юрий Шабалин: На банковский сектор распространяется государственное регулирование, банки обязаны проходить пентесты, заботиться о своих пользователях и сохранности их денег и, конечно, они сильнее других озабочены защищенностью данные.

Второй сегмент, для которого защищенность мобильных приложений важна – это e-commerсe.

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

В последнее время набирают популярность различные сторы на базе Android, на которые также можно установить приложения. Мы начали тестировать и их.

Юрий Шабалин: Развитие предполагает расширение алгоритмов анализа, углубление существующего функционала и внедрение дополнительных практик. Например, поиск уязвимых Open Source – компонентов, расширение атак не только на мобильные приложения, но и проверка их бэкенда, и, естественно, интеграция с внешними системами, различными дефект-трекерами, и потенциально выход на новые платформы.

Юрий Шабалин: Все зависит от политической ситуации в мире, но мы готовы выходить на рынок СНГ, активно сотрудничаем с представительствами различных компаний. Видим в этом большой потенциал.

Антон Башарин: Первый и главный из принципов – Shift + Left, сдвиг влево, означающий, что идентифицировать проблему нужно как можно раньше. Если сделать это накануне выхода релиза, а то и после него, это может очень дорого обойтись и во времени на устранение уязвимостей, и в деньгах, которые придется на это потратить.

Конечно, для внедрения этого принципа нужна внутренняя зрелость в компании. Хорошо, что в некоторых секторах, особенно в финансовом, драйверами выступают внешние стимулы, например, регуляторные требования ЦБ об обязательном проведении определенных процедур и проверок.

Но действительно можно отметить тренд 2024-2025 годов, когда крупные промышленные компании начали переходить к принципам DevSecOps без регуляторного принуждения, просто адекватно оценивая собственные риски.

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

Антон Башарин: Начнем с такого процесса, как версионирование. Закончив работу над каким-то фрагментом кода, разработчик делает коммит, появляется промежуточная версия, которую нужно сохранить в репозитории. Эту базовую функцию обеспечивает наш продукт AppSec.Code. Конечно, он умеет не только это. В его функционале автоматическая сборка, развертывание на стенде, промежуточные проверки кода с точки зрения информационной безопасности.

Второй процесс – анализ зависимостей, то есть не собственного кода, а компонентов с открытым кодом, различных фреймоворков, утилит и так далее. Разумеется, разработчики не пишут весь код с нуля. Более того, в большом проекте доля компонентов-зависимостей может составлять 90-95%.

Проводить их проверку на безопасность силами ИБ-команды просто нереально. Да и не нужно, потому что для этого есть AppSec.Track.

У него есть база знаний, обновляемая 24/7, к которой могут обращаться разработчики клиента и оперативно получать информацию, содержит ли зависимость уязвимости и если да, то какого они типа и уровня опасности. В итоге с помощью AppSec.Track собирается SBOM-файл (Software Bill of Material), в котором описываются все уязвимости.

Антон Башарин: Да, их безопасность помогает обеспечить наш продукт «Стингрей». В каждом приложении разработчики выстраивают набор политик, что приложению позволено делать, а что нет. Так, оно не должно требовать избыточных прав, обращаться к несвойственным для его работы папкам в файловой системе, сохранять секреты только в закрытых областях, то есть, например, не сохранять пин-ког и пароль в областях памяти, к которым могут иметь доступ другие приложения и т.д. Необходимо выявлять нарушение таких политик как в поле зависимостей, так и в поле собственного кода. После сборки приложение начинает напоминать «черный ящик», в том числе, и с точки зрения вопросов информационной безопасности.

А «Стингрей» приоткрывает этот ящик, эмулирует работу приложения в Android или непосредственно запуская его в iOS. Тесты как раз позволяют выявить проблемы в ИБ, которые должны решать разработчики.

Антон Башарин: Да, он тоже нуждается в комплексном управлении. Это позволяет делать AppSec.Hub. В крупной организации может быть 100 репозиториев исходного кода, и это норма, а далеко не максимум. В то же время на рынке (и в портфеле AppSec. Solutions) есть десять типов сканеров, и в каждом типе их может быть не по одному.

Каждый сканер хорош именно в своей области. И вот это разнообразие инструментов накладывается на огромные объемы кода, выявляются в буквальном смысле тысячи и десятки тысяч уязвимостей. Работать с такими данными в ручном режиме невозможно. Да и не нужно – ведь для этого есть AppSec.Hub.

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

Антон Башарин: Да, на базе наших собственных разработок в сфере искусственного интеллекта. Без его помощи ручной труд ИБ-инженеров становится «бутылочным горлышком», которое тормозит работу всей команды. Ведь, как правило, один ИБ-инженер приходится на сто, а то и на тысячу разработчиков.

Антон Башарин: Мы очень много работали над представлением данных, над их визуализацией, и в итоге получился очень информативный и адаптивный дашборд.

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

Например, в сфере финансов действуют установленные Банком России так называемые уровни доверия, и только при ОУД-4 и выше ваш продукт можно выводить на рынок.

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

Антон Башарин: Если мы выходим в «чистое поле», все просто. С нуля благодаря нашему опыту и нашим решениям выстроить процессы безопасной разработки вполне реально за несколько недель. Когда в компании уже сформированы процессы обеспечения информационной безопасности, часто неэффективные, перестроить ее работу сложнее, но, безусловно, тоже реально.