Доверие к мобильным SDK

Автор: admin от 14-01-2019, 14:05, посмотрело: 27

Доверие к мобильным SDK


Недавняя история о бэкдоре в популярнейшей NPM-библиотеке заставила многих задуматься о том, насколько мы доверяем стороннему коду и как смело используем его в своих проектах (потенциально подставляя тем самым пользователей наших продуктов).



Но ещё за месяцы до того, как «гром грянул», Феликс Краус (известный мобильным разработчикам как создатель Fastlane) говорил на нашей конференции Mobius 2018 Piter о похожем: доверии мобильных разработчиков к сторонним SDK. Если мы скачиваем популярный SDK от известной компании, то вот там-то всё хорошо, или тоже что-то может пойти не так? Где тут есть вектор атаки и о чём нам стоит задумываться в связи с этим?



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

писал в своём блоге несколько месяцев назад. На то, чтобы воссоздать вид, ушло 20 минут.



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



Если вы думаете, что есть сложность в том, чтобы получить адрес почты, к которому привязан Apple ID, то вы преувеличиваете: это можно сделать и через книгу контактов, и через контейнеры iCloud (при наличии доступа приложения к iCloud, о котором вы можете узнать из UserDefaults данного приложения). А самый простой вариант — попросить пользователя лично ввести свой имейл: по идее, это даже не должно вызвать у него удивления, ведь в iOS действительно существует разновидность окошка, запрашивающего не только пароль, но и имейл.



Я подумал: «Что, если взять этот имеющийся у меня код формы запроса и при помощи подмены SDK проникнуть с ним во много разных приложений, чтобы похищать с помощью них всех пароли от iCloud?» Насколько сложна эта задача?



Доверие к мобильным SDK


Предположим, у нас есть совершенно чистый Mac, без каких-либо установленных на него VPN или прокси, но в той же сети есть наш Raspberry Pi. На Mac в Xcode у нас открыт проект iOS-приложения, содержащего абсолютный минимум кода — простое отображение карты местности и не более того.



Теперь открываем браузер, заходим на Amazon Web Services. Находим страничку AWS Mobile SDK и переходим по ссылке на скачивание. Распаковываем скачанный бинарник и перетаскиваем все фреймворки внутрь нашего проекта в Xcode. Затем импортируем библиотеки. От нас даже не требуется вызывать какой-то код — достаточно того, что он будет загружен. Замечу, что в ходе всего процесса Xcode не выдал никаких предупреждений.



Что же происходит при перекомпиляции приложения? На экране появляется та самая копия окошка, предлагающая мне авторизоваться в iTunes Store. Я ввожу пароль, окошко исчезает. Параллельно наблюдая за логом приложения, я вижу как в нём моментально отображается введённый мной пароль — перехват данных Apple ID выполнен. Несложно было бы отправить эти данные куда-то на сервер.



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



И опять-таки, много ли нам понадобилось, чтобы осуществить атаку? Нужно было, чтобы в сети находился наш компьютер (и Raspberry Pi оказалось достаточно). HTTP или HTTPs — в данном случае не имело значения, шифрование бы не спасло ситуацию. Все использованные мной программные средства — самые простые, были взяты мной из публичного доступа. При этом я — обыкновенный разработчик, без особого знания и опыта взломов.



Перехват управления



Предыдущий пример внедрял зловредный код в iOS-приложение. А что, если бы нам удалось заполучить контроль над компьютером разработчика вообще? Возможность запустить код на вашем устройстве, как вы понимаете, даёт хакеру огромную власть. Он сможет активировать удалённый доступ через SSH, установить кейлоггер и т.д. Он сможет в любое время наблюдать за вами, фиксировать ваши действия, пользоваться файловой системой. Также он сможет устанавливать новые сертификаты SSL и с помощью них перехватывать все запросы, производимые вами в сеть. Словом, у кого-то есть возможность запустить код на вашем компьютере — и вы полностью скомпрометированы.



Я подумал: «что из iOS SDK я могу использовать для этого?» Есть сервис, предоставляющий SDK посредством команды curl и ссылки HTTP с перенаправлением вывода команде sh. То есть ваш терминал скачает и запустит shell-crhbgn&



Доверие к мобильным SDK


Сам по себе такой способ установки уже подвергает вас риску, не делайте так. Но в данном случае ещё и использовался протокол HTTP. Что в таком случае возможно сделать?



Доверие к мобильным SDK


Предположим, вы — пользователь. Вы заходите на официальную страницу документации. Обращаете внимание на то, что страница шифрована протоколом HTTPS — здорово! Вы копируете команду, запускаете её у себя. Команда выполняется в течение нескольких секунд. Что же успело произойти за это время?



А за это время успел сработать несложный механизм атаки с участием моего Raspberry Pi. Загруженный пользователем shell-скрипт «UpdateSDK» содержал небольшое вкрапление моего собственного кода. И теперь мне разрешён удалённый доступ к вашему компьютеру через SSH, а также у вас был установлен кейлоггер.



Доверие к мобильным SDK


Слева вы видите «ваш» терминал, а справа — мой Raspberry Pi, который в режиме реального времени уже показывает всё, что вы вводите на клавиатуре. Запустив с Raspberry Pi SSH, я авторизуюсь, используя логин и пароль, только что прописанные при помощи кейлоггера, и таким образом получаю полный доступ к управлению вашим Mac и к его файловой системе. А также, вероятно, доступ ко многому у вашей компании-работодателя.



В заключение



Насколько вероятно, что такое может произойти с вами? Ведь разработчики всё же стараются использовать безопасный Wi-Fi, покупают себе VPN.



Лично я тоже думал, что осторожен, пока однажды не открыл настройки своего Mac и не обнаружил в истории более 200 подключений к небезопасным сетям Wi-Fi. Каждое такое подключение — это потенциальная угроза. И даже пользуясь проверенной сетью, вы не можете быть на 100% уверенными в своей безопасности, так как не можете знать, не было ли скомпрометировано какое-нибудь из устройств этой сети (как мы только что увидели).



Атаки через небезопасные сети Wi-Fi происходят очень часто. Их легко проводить в публичных местах, таких как гостиницы, кафе, аэропорты и, кстати, конференции :) Представьте, спикер рассказывает о каком-нибудь SDK, и, как водится, параллельно часть зрителей пробует его установить, подключившись к раздаваемому здесь Wi-Fi. А как я уже говорил, злоупотребить своими правами сетевому провайдеру очень легко.

Точно так же и с VPN — вы просто передаёте себя в руки провайдера. И кому лучше довериться — VPN-провайдеру или своей локальной сети и её пользователям? Неясно.



В ноябре 2017 года я провёл своё исследование и проанализировал на наличия в них перечисленных уязвимостей топ 41 самых популярных SDK для iOS (не считая SDK от Google и Facebook, они все надёжно защищены).



Доверие к мобильным SDK


Как видите, 31.7% SDK не прошли тестов. Об имеющихся проблемах я сумел сообщить почти всем поставщикам. От одного я получил ответ буквально сразу же, проблема была решена в течение трёх дней. Пятеро команд тоже отреагировали, но потратили на доработку чуть больше времени — около месяца. Семеро же не потрудились ответить на мой репорт вообще и так и не исправили ничего по сей день. Напомню, речь не о каких-то малоизвестных проектах. Все они входят в число самых известных SDK и имеют десятки тысяч пользователей, разрабатывающих с помощью этих SDK iOS-приложения, которые, в свою очередь, используют миллионы пользователей iPhone.



Важно понимать, что пользователи закрытых приложений всегда подвержены большим рискам, пользовали опенсорсных — меньшим. Вы не можете проверить, как работает закрытое приложение. Крайне сложно судить о наличии в нём безопасных решений. Вы можете сравнивать хеши и хеш-суммы, но этим вы, максимум, сумеете проверить успешность загрузки. Опенсорсные продукты, напротив, вы можете исследовать основательно, вдоль и поперёк, а значит, сможете обеспечить себе больше защиты.



Помимо атак man-in-the-middle, существуют и другие. Хакер может атаковать сервер, с которого осуществляется загрузка SDK. Бывает также, что компания, поставляющая SDK, намеренно включает в код так называемые бэкдоры, через которые она впоследствии сможет осуществлять несанкционированный доступ к устройствам пользователей (возможно, местное правительство требует устанавливать бэкдоры, а возможно, это инициатива самой компании).



А мы несём ответственность за продукт, который поставляем. Мы должны быть уверены, что не подводим пользователя и соблюдаем GDPR. Атаки через SDK серьёзны в первую очередь потому, что они массовы — направлены не на одного разработчика, а на миллион пользовательских устройств за раз. Эти атаки могут проходить почти незаметно для вас. Открытый исходный код помогает вам защититься от такого, с закрытым всё гораздо сложнее — используйте его только когда можете смело ему доверять. Спасибо за внимание.



Если вам понравился этот доклад, обратите внимание: следующий петербургский Mobius состоится 22-23 мая, билеты уже в продаже, и постепенно они дорожают.


Источник: Хабр / Интересные публикации

Категория: iOS

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

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *