Во второй половине 2017 года в Google Play разработчики загружали примерно по 2800 приложений каждый день. По AppStore данные пока не удалось найти, но вряд ли во много раз меньше. Каждое из этих приложений содержит определённое количество данных (data), которые хранятся или передаются через сотовые и Wi-Fi-сети.

Источник

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

Немного о себе

Меня зовут Юрий, я 10 лет занимаюсь вопросами в различных областях информационной безопасности, в том числе приватности и утечки данных. Области практического интереса — мобильная безопасность, облачные вычисления, криминалистка и управление безопасностью и доступом. Последние 7 лет выступаю на отечественных и международных конференциях (CyberCrimeForum, HackerHalted, DefCamp, NullCon, OWASP, CONFidence, Hacktivity, Hackfest, DeepSec Intelligence, HackMiami, NotaCon, BalcCon, Intelligence Sec, InfoSec NetSysAdmins, etc.), где предлагаю вниманию разработчиков небезынтересные примеры небезопасности и последствий и прошу их чуть больше задумываться о безопасности данных.

Как разработчики могут повлиять на безопасность

Существует много разных мнений относительно оказываемого разработчиком влияния на безопасность.

1. «Разработчик не всегда своевременно реагирует на отчёты безопасности, в которых отмечаются недостатки приложений».
2. «Разработчик сделал всё, что было в его силах, чтобы обеспечить безопасность, поэтому любые возникающие проблемы — только из-за действий пользователей» (Это может продолжаться до тех пор, пока ситуация не будет предана огласке, зачастую с привлечением журналистов, и то, эффект продлится недолго)
3. «Стоит прекратить обвинять разработчиков во всех грехах безопасности» (появилось относительно недавно). Другими словами, разработчики — не единственные, кто задействован в создании приложения или продукта.
   Например, есть тестировщики и менеджеры продукта. При этом каждый выполняет свою роль, что в сумме позволяет убедиться в общей безопасности разрабатываемого решения. Мнение было опубликовано в статье около года назад. Пункт о разделении обязанностей по ролям несколько раз повторялся в параграфах и дополнялся выводом, что проблемы безопасности случаются всегда, когда кто-то развивает прототип до коммерчески успешного продукта. Но разделение по ролям предполагает и разделение ответственности, поэтому претензии относительно безопасности приложения могут и не достигнуть своего адресата. Подобные заявления снижают внимание к безопасности, а разработчики не чувствуют за это ответственности до тех пор, пока информация о проблемах не станет публичной.
   Разработчики всегда были и будут первыми, кто работает с приложениями и может сразу же исправить в них проблемы и сделать более безопасными. Проактивность уже на ранних этапах также помогает разработчикам поддерживать достаточный уровень безопасности. Тем не менее, пользователи должны иметь в виду, что есть не зависящие от разработчика временные рамки устранения проблем. Так, если разработчик просто хочет обновить приложение, он создаёт новую сборку, отправляет её в магазин приложений и ждёт, пока её одобрят модераторы (требуется несколько дней), затем необходимо дождаться обновления приложений, если автоматическое обновление на устройстве пользователя было выключено. Таким образом, разработчик отчасти контролирует процесс. Возникает вопрос, стоит ли культивировать и поощрять подобные задержки? Это контрпродуктивно, ведь разработчик, зная эту ситуацию лучше других, может спланировать заранее, например, внедрение новых функциональных возможностей, исправление ошибок безопасности, и в целом может иметь чек-лист, указывающий, что нужно успеть выполнить в срок при каждом обновлении.

Вроде всё по best practice, а приглядишься — беда…

У людей есть много потребностей (личных, профессиональных, рабочих); два и более устройства и, как следствие, более одного поставщика услуг и десятки приложений для удовлетворения своих нужд. Несмотря на такую гибкость и разнообразие, разное программное обеспечение имеет много общих свойств. Например, одни и те же технологии хранения, передачи и защиты данных, даже учитывая различную реализацию, могут иметь сходство на уровне архитектурных особенностей.

Что касается механизмов безопасности, часть из них уже работает по умолчанию и не требует вмешательства разработчика, а другие — наоборот. Например, SSL/TLS, который применяется во многих приложениях, уязвим для атак Man-in-the-Middle (MITM), когда дело доходит до неправильной реализации. При этом в iOS 10 (и выше) и Android 7 (и выше) уже встроены механизмы предотвращения MITM-атак, которые также помогают избежать правительственного перехвата данных со стороны таких стран, как Казахстан и Таиланд.

Причём эти механизмы включены по умолчанию вне зависимости от действий разработчика, но по-разному реализованы. Также Android имеет полностью независимый механизм, а iOS — управляемый, что позволяет активировать работу сторонних SSL-сертификатов.

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

У этой дыры в заборе есть даже своя страница на Викимапии

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

Результаты проверок безопасности данных за 4 года

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

• Без защиты — данные хранятся или передаются без какой-либо защиты и шифрования, «как есть, в открытом виде».
• MITM без корневого сертификата (отсутствует в приведённых примерах, но до весны 2017 таковым примером являлся AeroExpress) – возможность перехвата данных с любым поддельным сертификатом.
• MITM + корневой сертификат — MITM-атака возможна, когда злоумышленник использует специальный сертификат, в т.ч. поддельный/украденный корневой SSL-сертификат для перехвата и расшифровки трафика. Случаи, когда пользователь вынужден установить самостоятельно, могут быть связаны с рекомендацией разработчиков, необходимостью соответствия требования конкретного государства (например, упомянутого Казахстана или Таиланда.
• SSL Пиннинг (тут или тут) — MITM-атака невозможна, если устройство не было взломано (нет выполненного джейлбрейка или рута) с учётом особенностей предыдущего пункта.
• Сильная защита — в общем смысле приложение защищено от атак и требует значительных усилий для получения данных; также следует понимать, что не использованы технологии HTTPS. Это важно, т.к. приложения активно и в подавляющем большинстве используют HTTPS ввиду простоты реализации и поддержки со стороны сервера. Вместе с этим существует большое количество инструментов перехвата данных, которые спроектированы именно под проблемы, связанные с HTTPS.
• Включение в резервную копию — позволяет получать доступ к дубликатам данных (меньшее или равное 100 % хранимых данных приложений) с помощью различных программ в т.ч. криминалистических решений без необходимости иметь устройство с выполненным джейлбреком или рутом. Есть данные приложение – они хранятся в рабочей папке приложения. Часть этих данных включается в резервную копию. При этом куда разработчик положит данные: в синхроинзиуемые в резервную копию папки или нет – это к разработчику вопрос (поэтому может достигаться 100% дублирование данных в резервной копии. Считается, что доступ к резервной копии проще получить без рута и джейлбрейка, чем выполнить рут и джейлбрейк (на новых устройствах, на старых это не принципиально).

Краткое объяснение типа данных:

• Все данные — информация об учётной записи, учётные данные, чаты, базы данных приложений и пользователя, конфигурационные и кэшированные данные — всё, что пользователь видел в своём приложении среди своих данных и документов.
• Медиаданные — все данные, включая фото-, видео-, аудиоинформацию (кроме медиапотоков).
• Данные Geo Docs — геолокация, связанная с пользовательскими документами, файлами и заметками, такими как координаты, описание места, адрес, город и т.д.
• Адресные данные местоположения — геолокация, не привязанная к конкретным элементам данных, но также представляющая координаты, описание места, адрес и город и т.д.
• Социальные учётные данные — имя пользователя/адрес электронной почты, пароль или токен вместо пароля (наиболее частая реализация), имеющие отношение к социальным сетям Facebook, Twitter, LinkedIn и т.д.).
• Фотолокации — информация о месте и адресе, с фотографиями этого места, например, изображение здания по адресу Х.
• Информация о приложении — всё, что доступно в настройках приложения внутри приложения: смена паролей, настройка кредитных карт, выбор доверенных друзей для доступа к потерянной учётной записи.
• Медиаданные аккаунта — мультимедийные файлы, относящиеся к учётным записям владельца и его друзей, другими словами, изображения профиля и кешированное изображение (для дальнейшей цели хранения на устройстве).

Показательные проблемы

Небезопасное хранение данных

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

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

Небезопасная коммуникация

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

Утечки данных

Многие популярные мобильные приложения, особенно игры, часто собирают огромное количество персональных данных для профилирования и персонализации владельца устройства. Сюда входят такие данные, как возраст, пол, геолокация, деятельность в социальных сетях, привычки (любимые маршруты, посещаемые заведения, музыкальные, кулинарные предпочтения) и многое другое. В этом случае существует вероятность, что по крайней мере 2, 3 или 5 приложений раскрывают максимальное количество информации о пользователе. Тем не менее сбор такой информации является нарушением требований многих документов и рекомендаций по безопасности с учётом целей и функций приложения. Проблема усугубляется тем, что пользовательские соглашения часто не отражают сути защитных механизмов или защищаемых данных или имеют неточности. А ещё их никто не читает.

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

Сторонний код

Использование сторонних библиотек помогает ускорить разработку и воспользоваться опытом других разработчиков в собственном приложении. Однако, такой опыт включает в себя и все проблемы, в том числе проблемы безопасности. Такая практика может фактически с точки зрения безопасности разделить защиту на две и более частей: один и тот же тип данных, например, пароль, будет найден в нескольких местах (разные пользовательские сценарии) и с разным уровнем защищённости (аналогично Facebook).

Отложенное исправление безопасности

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

В долгосрочной перспективе нет надёжного приложения

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

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