Всем привет!

И снова с вами я, Юрий Шабалин, ведущий архитектор Swordfish Security и генеральный директор Стингрей Технолоджиз. Как вы помните, мы разрабатываем систему автоматизированного анализа защищенности мобильных приложений, о которой я рассказывал в прошлых статьях.

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

Оглавление

• Введение

• Разбираемся с мифами

  • #1. Мобильное приложение — это только один пользователь

  • #2. Мобильное приложение — всего лишь витрина данных для серверной части системы

  • #3. Приложения проверяют внутри магазинов

  • #4. Никому нет дела до репутационных рисков

  • #5. Можно надеяться на операционную систему

• Вывод

Введение

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

• Мобильное приложение — это только один пользователь и его безопасность, а вот серверная сторона содержит данные всех клиентов, поэтому именно ее и нужно защищать

• Мобильное приложение — это всего лишь витрина данных для серверной части системы, аналог front-части, там не может быть ничего, что нужно злоумышленнику

• Мобильные приложения и так проверяются на стороне Google и Apple перед публикацией, зачем же делать лишнюю работу?

• Мобильные приложения не подпадают под требования регуляторов

• Операционные системы сами по себе предоставляют эффективные средства защиты данных, а значит, и данные приложения находятся в безопасности

И то, о чем вслух обычно не говорят:

• Атаки на мобильные приложения могут повлечь за собой не самый большой ущерб, который покроется рисками и не повлияет на KPI

• У мобильных приложений узкий вектор атаки, для которого часто необходим физический доступ, а значит, клиент будет виноват сам и это не отразится на показателях отдела по убыткам

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

Разбираемся с мифами

#1. Мобильное приложение — это только один пользователь

Есть одна вещь, о которой после долгих лет, проведенных в безопасности, мы часто забываем. В первую очередь мы работаем для обеспечения безопасности пользователей. Мы выстраиваем процессы, внедряем инструменты и выполняем разные задачи для того, чтобы наши клиенты были защищены, чтобы их личные данные, переписки, деньги — всё, что хранится, в том числе, в мобильных приложениях, — не попало в руки злоумышленников. Поэтому странно слышать высказывания, утверждающие, что безопасность не важна, если под угрозой находится только один клиент, который пользуется приложением, и что связанные с этим риски минимальны, их можно не учитывать, поскольку они не влияют на KPI. Представим на минутку, что у того самого единственного клиента взломали аккаунт и скомпрометировали важные переписки по рабочим вопросам, а тем, кто принял решение закрыть глаза на безопасность, оказались именно вы. Немного неприятно, не правда ли? Рано или поздно статистика перестает быть просто цифрами, когда дело касается лично вас.

«Но, видно, всегда так бывает: смерть одного человека – это смерть, а смерть двух миллионов – только статистика» (Эрих Мария Ремарк).

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

А сейчас попробуем посмотреть на уязвимости мобильных продуктов с другой стороны. Допустим, в нашем приложении нашлась проблема безопасности, которая позволяет получить важные клиентские данные (пароли, аутентификационные токены, личную информацию и многое другое) — их можно использовать для дальнейших атак на пользователя. С одной стороны, действительно, в данном случае уязвимость затрагивает только одного клиента. Но ведь пользователей приложения очень много, и каждый из них потенциально может стать жертвой из-за этой проблемы. В истории есть немало примеров, когда внутри обычных легитимных продуктов, загруженных из официальных магазинов, находилась дополнительная функциональность, с помощью которой можно было получать данные из других приложений.

Например, поддельное приложение Club House для Android выполняло все необходимые задачи оригинального продукта, но вместе с этим пыталось украсть аутентификационные данные огромного количества (около 450) популярных сервисов. Учитывая, что официальное iOS-приложение скачали свыше 13 миллионов раз, думаю, многие учетные данные были скомпрометированы. Или возьмем приложение, которое мы загрузили в магазин в качестве эксперимента во время исследования одной из уязвимостей в системе Android. Оно заменяло собой Google Photo и до недавнего времени было доступно в Google Play (на момент выхода статьи приложение удалено, так как мы вовремя его не обновили, чтобы соответствовать политикам). Сколько таких приложений есть в официальных магазинах — никто не знает. На альтернативных сервисах и сайтах их также может быть очень много.

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

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

#2. Мобильное приложение — всего лишь витрина данных для серверной части системы

Это очень распространенное мнение, которое правдиво лишь отчасти. Действительно, мобильное приложение можно рассматривать, как некий Front для серверной стороны. Так же как и Web-часть, приложение выполняется на устройстве пользователя и отображает данные, поступающие с сервера. Но часто забывается одна очень важная вещь — то, что находится на стороне пользователя в мобильной версии, сильно отличается от аналогичного приложения в браузере. Это обязательно нужно иметь в виду, ведь мобильные клиенты становятся все популярнее. Согласно данным Росстата, 78,1% опрошенных используют мобильные устройства, а по данным Тинькофф (Tinkoff Strategy Day 2018), количество клиентов мобильных приложений уже в 2018 году превысило число пользователей Web-версий, и разрыв продолжает расти. Такая популярность заставляет разработчиков совершенствовать мобильные продукты. Для этого некоторые важные данные иногда сохраняются локально, кэшируются, а то и вовсе используется «локальная» аутентификация (например, проверка пин-кода для входа в приложение проводится на устройстве, а не на сервере) — в случае, если серверная часть не может поддержать изменения достаточно быстро, а функционал требуют прямо сейчас.

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

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

Суть атаки сводилась к простым вещам: злоумышленник переходил на страницу, получал идентификатор сессии, подставлял его в параметр запроса и получившуюся ссылку отправлял жертве. Пользователь открывал ссылку, аутентифицировался в сервисе, сервер поднимал значение сессии до уровня аутентифицированного клиента, и бинго — злоумышленник получал доступ к аккаунту жертвы. Но вот ведь незадача — несмотря на то, что этот токен передавался в параметрах GET-запроса (что уже само по себе не очень хорошо), проэксплуатировать эту проблему с Web не получалось. Каждый раз, когда пользователь переходил на страницу, идентификатор обновлялся. Но не в случае с мобильным приложением, в котором присутствовала функциональность обработки deeplink (при открытии определенной ссылки система предлагает посетить источник через приложение, а не сайт). Вектор злоумышленника немного менялся, ему нужно было чуть-чуть по-другому сформировать ссылку, чтобы при открытии на мобильном устройстве система предлагала перейти в приложение. Вот в приложении как раз этот идентификатор учитывался и передавался на сервер, который и повышал сессию до авторизованной. То есть для успешной атаки на пользователя требовалась именно связка недостатков в нескольких частях системы.

Еще один аргумент, подтверждающий, что защите приложений нужно уделять внимание, состоит в том, что мобильные продукты часто хранят различную чувствительную информацию либо в коде самих приложений, либо в данных, которые они сохраняют на устройствах. Как ни странно, токены от сторонних или внутренних сервисов, ключи шифрования, логины/пароли редко встречаются в коде Web-приложений, а ведь они также выполняются на устройствах клиентов, но почему-то никто не сохраняет эти данные в хранилище браузера. Так почему же тогда такое поведение допускается по отношению к мобильным приложениям, раз это тоже Front-система? Возможно, не все еще привыкли к тому, что добыть и проанализировать строки из файла приложения или выполнить декомпиляцию и получить практически исходный код Android-приложения достаточно просто. И, возможно, не все еще понимают, как работают атаки и как можно проэксплуатировать различные уязвимости в приложениях. Это подтверждает и мой опыт. Однажды в ответ на отчет об уязвимостях в приложении мне ответили буквально следующее: «В приложении уязвимостей быть не может, код скомпилирован» [(с) — подрядчики одного крупного Банка].

А в приложениях очень часто хранится много полезной для атакующего информации, например, данные тестовых серверов, логины и пароли от технических учетных записей. Также к ней можно отнести ключи от внешних сервисов, которые часто используют в мобильных приложениях (мы уже писали об этом в статье по поиску и верификации подобных секретов), например, для отправки push-уведомлений, реализации функционала карт, интеграции с соцсетями и многими другими сервисами. Зачастую эти ключи обладают намного большими привилегиями, по сравнению с тем, что необходимо для клиентского взаимодействия (или они вообще не нужны в приложении, и их оставили там по ошибке). У нас был случай, когда в одном из приложений мы нашли скрипты сборки и файл с зависимостями, которые содержали в себе версии всех библиотек, включенных в продукт, адреса внутренних стендов и систем CI/CD, а также контакты некоторых разработчиков в Telegram. Вся эта информация может стать очень хорошей отправной точкой для дальнейшей атаки на компанию или ее пользователей.

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

#3. Приложения проверяют внутри магазинов

Довольно часто я слышу аргумент про то, что магазины перед публикацией проверяют приложения и уведомляют разработчиков при обнаружении каких-то проблем. Действительно, гиганты вроде Google Play или Huawei анализируют продукты перед тем, как предложить их публике. Но что именно они проверяют, на что обращают внимание — это уже совершенно другой разговор.

В сентябре прошлого года мы изучили 790 приложений, загруженных из популярных магазинов, на наличие самых распространенных недостатков и уязвимостей. Результаты показали, что 83% мобильных продуктов содержат проблемы высокого и критического уровней.

По большому счету, Google или Apple без разницы, насколько уязвимо ваше приложение и какие данные оно в себе содержит. В основном они смотрят на то, чтобы оно не было вирусом или модификацией какого-нибудь malware, не нарушало бы правил магазина (например, не использовало бы приватные системные API). Также они проверяют, насколько корректно владелец составил описание и насколько качественно сделал скриншоты. То есть магазины обращают внимание только на то, что им выгодно: на злоупотребление различными функциями системы или попытки «обмануть» ее, вызвав какое-то API напрямую. Они защищают прежде всего себя и свою репутацию, определяют, насколько приложение соответствует их правилам — не более того.

При исследовании программ, которые предоставляют подобные сервисы по анализу приложений, я наткнулся на достаточно интересные правила Google Play в части проверки на уязвимости и возможной блокировки публикации до устранения проблем (ознакомиться с ними можно здесь). Подразумевается, что при публикации выполняется сканирование приложения и в личный кабинет приходит уведомление с результатами проверки. Но честно говоря, я никогда не видел подобных сообщений (если кто-то сталкивался с таким, напишите, пожалуйста, об этом в комментариях). Более того, реальные уязвимости, как правило, находят именно в релизных версиях приложений, которые уже опубликованы, поэтому в качестве такой проверки я бы усомнился. И это подтверждает публикация нашего «вредоносного» приложения, о котором я писал чуть выше. Во-первых, в названии пакета содержалось слово malware (что никак не повлияло на публикацию), во-вторых, наше приложение было основано на крайне уязвимом продукте (созданном нами специально для CTF), который содержал большое количество проблем — и никаких уведомлений мне не поступало. Ну и в-третьих, публикация приложения заняла около 15-20 минут, я сомневаюсь, что за это время что-то успели проверить.

Во время исследования я также обратил внимание на магазины Samsung GalaxyStore и Huawei AppGallery. Они заявляют в своих материалах, что проверяют приложения на уязвимости перед публикацией, но никакой подробной информации об этом я не нашел. Как это происходит, какие критерии используют, какой анализ проводят — ничего. А учитывая то, что порой и в самих приложениях магазинов находят серьезные уязвимости, вопросов к качеству таких проверок остается немало. Забавный момент: для того, чтобы опубликовать приложение в AppGallery для региона КНР, к заявке необходимо приложить отчет о проверке от внутренней службы безопасности Республики — вот это я понимаю подход. В качестве следующего шага нашего исследования мы опубликуем самое уязвимое приложение во все сторы и сравним, что они покажут в части анализа безопасности и пустят ли вообще такое решето в магазин.

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

Правила и требования безопасности для этих приложений могут быть сильно смягчены (если вообще к ним предъявляют подобные требования), так как это не внешний периметр компании, и чтобы добраться до какого-то из сервисов, нужно сначала попасть внутрь инфраструктуры. Но не в случае с мобильными приложениями. Мы всегда должны помнить, что продукты со слабыми требованиями безопасности, разработанные для внутреннего использования и, вероятно, содержащие конфиденциальные данные, функционируют на внешних, неконтролируемых мобильных устройствах сотрудников. Что будет, если чей-то смартфон украдут, или он потеряется? Конечно, вероятность, что этот риск реализуется, не такая уж и большая, но и сбрасывать со счетов эту угрозу не стоит. Если в вашей компании есть внутренние маркетплейсы, поинтересуйтесь, насколько безопасны их приложения, и что они в себе хранят.

#4. Никому нет дела до репутационных рисков

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

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

В рамках прошлогоднего исследования, упомянутого мной ранее, мы нашли 10 приложений, которые содержали в себе уязвимость, позволяющую отправить Push-уведомление на все устройства, на которых установлен уязвимый продукт. Злоумышленники могли передать произвольный заголовок, текст, картинку, gif-файл и другие медиа-элементы, допустимые в Push-уведомлениях. В таких случаях сообщение приходит от имени приложения (бренда), поэтому вызывает доверие пользователя.

Эта уязвимость может быть использована для целей социальной инженерии. Например, с помощью нее можно отправить Push-уведомление от банка с содержанием: «Банк предотвратил списание всех средств с вашей карты. Немедленно обратитесь в службу безопасности по телефону xxxx».

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

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

И напоследок еще один пример — отправка сообщения о том, что приложение было взломано и все данные теперь в руках мошенников. Таких уведомлений может поступить неограниченное количество (10-20-100 сообщений за несколько минут). Это точно напугает/насторожит клиентов и отобьет у них желание пользоваться услугами компании.

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

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

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

#5. Можно надеяться на операционную систему

Это моя любимая история. Я уже писал о том, что самой распространенной проблемой в мобильных приложениях является хранение конфиденциальной информации в открытом виде на устройстве. За прошлый год мы провели огромное количество автоматизированных сканирований, а также ручных проверок мобильных приложений. Результат тот же — приложения продолжают сохранять или кэшировать значительную часть данных пользователя в открытом виде. В свою защиту компании приводят следующий аргумент: «Мы сохраняем данные внутри песочницы приложения, которая управляется операционной системой, эти данные получить невозможно».

На самом деле это не так. Данные можно получить с помощью банальных облачных и локальных бэкапов: согласно нашему исследованию, не менее 37% проанализированных Android-приложений разрешают создавать локальные резервные копии. Еще один способ — использовать уязвимости самого приложения, которые позволяют читать произвольные файлы внутри песочницы. Также сделать это позволит самый обыкновенный root или jailbreak доступ на устройствах, так как далеко не все приложения определяют запуск в скомпрометированной среде.

Из последних наблюдений — излишнее доверие к библиотекам, которые осуществляют «безопасное» хранение данных на устройстве. Речь идет о набирающем популярность Flutter, а именно о плагине, который обещает безопасно сохранить данные на устройстве. В случае с Android это действительно так. Плагин достаточно неплохо умеет шифровать и сохранять информацию. Но вот для iOS он лишь сохраняет передаваемые в него данные в открытом виде в KeyChain. То есть, если вы захотите сохранить пароль или пинкод пользователя (что уже само по себе не очень хорошо) и используете этот плагин в приложении для iOS, то на выходе вы получите сохраненный в открытом виде в KeyChain пароль от аккаунта пользователя. Несмотря на то, что это хранилище считается защищенным, крайне не рекомендуется содержать в нем данные в открытом виде, так как они могут быть получены через локальный или облачный бэкап, при физическом доступе к устройству или при наличии Jailbreak. А в некоторых случаях их можно добыть и при продаже устройства, если разработчик не имплементировал очистку KeyChain после переустановки продукта. При удалении приложения данные KeyChain сохраняются, в отличие от информации, находящейся в песочнице приложения (файловой системе). Если пользователь продаст свое устройство без сброса к заводским настройкам, покупатель может получить доступ к учетным записям приложений и данным предыдущего пользователя, просто установив приложение и посмотрев, что оно хранит в сумке ключей.

В Android же существует как минимум три способа добыть данные из песочницы приложения. Это может быть уязвимость при реализации Content Provider, сохранение данных на SD-карте (особенно часто этим грешат сторонние библиотеки), а также классический бэкап данных приложения.

Не стоит забывать и о том, что нередко применяемые технологии шифрования далеки от идеальных. Мы часто наблюдаем использование «зашитого» в коде приложения ключа шифрования — очень классный пример с разбором очередного безопасного хранилища ваших приватных фотографий (более 10 миллионов установок), который мало того что использует устаревший DES-алгоритм, так еще и ключ шифрования “12345678“ у него находится в исходном коде. Также встречаем хранение ключа рядом с зашифрованными данными в соседнем файле, а также многие другие проблемы, связанные с неправильным применением шифрования и хэширования.

Поэтому не стоит слепо надеяться на механизмы защиты операционной системы. Помимо уязвимостей, которые бывают в них самих и в системных приложениях, существует еще масса способов получить данные из песочницы. Если вы это читаете, запомните — всё что хранится или проверяется локально, можно получить или обойти.

Вывод

Этот материал — крик моей души, который я копил долгое время. Конечно, многие компании уже давно занимаются безопасностью мобильных приложений, за что им хвала и честь. Но есть и те, кто еще не задумывался об этом или просто не понимает всех последствий “прохладного“ отношения к защите.

Не стоит надеяться на мифические проверки магазинов приложений или считать, что мобильные продукты — это отображение данных серверной части. Всё уже давно не так.

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

Я с удовольствием пообщаюсь с вами на темы, освещенные в статье, и отвечу на все комментарии.

Спасибо большое за ваше время и внимание, у меня всё!

С вами был Юрий Шабалин, до связи!